perm filename COMSCH.MSG[SCH,LSP]34 blob
sn#885502 filedate 1990-07-03 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00452 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00076 00002
C00077 00003 ∂17-Jun-89 2139 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #139
C00081 00004 ∂18-Jun-89 2215 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #140
C00087 00005 ∂19-Jun-89 1414 @mc.lcs.mit.edu:mkatz@sesame.stanford.edu another change for R4RS peek-char
C00092 00006 ∂19-Jun-89 1851 @mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu another change for R4RS peek-char
C00098 00007 ∂19-Jun-89 1852 @mc.lcs.mit.edu:mkatz@sesame.stanford.edu another change for R4RS peek-char
C00106 00008 ∂19-Jun-89 1906 @mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu another change for R4RS peek-char
C00112 00009 ∂19-Jun-89 1907 @mc.lcs.mit.edu:mkatz@sesame.stanford.edu another change for R4RS peek-char
C00119 00010 ∂19-Jun-89 2242 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #141
C00129 00011 ∂20-Jun-89 0721 @mc.lcs.mit.edu:shaff@sesame.stanford.edu Useful, but not essential
C00133 00012 ∂20-Jun-89 0754 @mc.lcs.mit.edu:shaff@sesame.stanford.edu Useful, but not essential: the reference
C00135 00013 ∂20-Jun-89 1323 @mc.lcs.mit.edu,@zermatt.lcs.mit.edu:ziggy@hx.lcs.mit.edu RE: Sticks and stones
C00138 00014 ∂20-Jun-89 1424 @mc.lcs.mit.edu,@ZERMATT.lcs.mit.edu:jinx@zurich.ai.mit.edu Sticks and stones
C00142 00015 ∂20-Jun-89 1428 @mc.lcs.mit.edu,@zermatt.lcs.mit.edu:mkatz@sesame.stanford.edu Sticks and stones
C00147 00016 ∂20-Jun-89 1437 @MC.lcs.mit.edu,@life.ai.mit.edu:Stewart.Clamen@clamen.avalon.cs.cmu.edu LIST-REF and LIST-TAIL
C00150 00017 ∂20-Jun-89 1500 @mc.lcs.mit.edu,@ZERMATT.lcs.mit.edu:cph@ZURICH.ai.mit.edu Sticks and stones
C00152 00018 ∂20-Jun-89 1542 @mc.lcs.mit.edu,@zermatt.lcs.mit.edu:mkatz@sesame.stanford.edu Sticks and stones
C00155 00019 ∂20-Jun-89 1644 @mc.lcs.mit.edu,@life.ai.mit.edu,@fog.cs.uoregon.edu:will@cs.uoregon.edu LIST-REF, LIST-TAIL
C00158 00020 ∂20-Jun-89 2306 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #142
C00170 00021 ∂21-Jun-89 1450 @mc.lcs.mit.edu,@life.ai.mit.edu:jinx@zurich.ai.mit.edu Librarian
C00173 00022 ∂21-Jun-89 1457 @mc.lcs.mit.edu,@life.ai.mit.edu:Gateley@tilde.csc.ti.com Re: LIST-REF and LIST-TAIL
C00177 00023 ∂21-Jun-89 2238 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #143
C00185 00024 ∂22-Jun-89 0706 @mc.lcs.mit.edu,@mojave.stanford.edu:shap@sid.stanford.edu Useful, but not essential
C00189 00025 ∂22-Jun-89 1210 @MC.lcs.mit.edu,@life.ai.mit.edu:mkatz@sesame.stanford.edu LIST-REF and LIST-TAIL
C00194 00026 ∂22-Jun-89 1257 @mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu [chaynes@iuvax.cs.indiana.edu: [will@cs.uoregon.edu: LIST-REF, LIST-TAIL]]
C00199 00027 ∂22-Jun-89 1913 @mc.lcs.mit.edu:Pavel.pa@xerox.com Responses to a month of mail
C00213 00028 ∂22-Jun-89 2146 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #144
C00216 00029 ∂23-Jun-89 0934 @mc.lcs.mit.edu:mkatz@sesame.stanford.edu Responses to a month of mail
C00221 00030 ∂23-Jun-89 1328 @mc.lcs.mit.edu,@mojave.stanford.edu:shap@sid.stanford.edu Responses to a month of mail
C00225 00031 ∂26-Jun-89 0648 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #145
C00232 00032 ∂26-Jun-89 2154 @mc.lcs.mit.edu:Alan@REAGAN.ai.mit.edu Responses to a month of mail
C00235 00033 ∂26-Jun-89 2155 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #146
C00237 00034 ∂27-Jun-89 1311 @mc.lcs.mit.edu:Pavel.pa@xerox.com Responses to responses to responses
C00243 00035 ∂27-Jun-89 1419 @MC.lcs.mit.edu:jinx@ZURICH.ai.mit.edu Responses to responses to responses
C00248 00036 ∂27-Jun-89 2001 @MC.lcs.mit.edu,@ZERMATT.lcs.mit.edu:SCHREQ@MC.lcs.mit.edu testing
C00250 00037 ∂27-Jun-89 2147 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #147
C00253 00038 ∂28-Jun-89 0847 @mc.lcs.mit.edu:jinx@ZURICH.ai.mit.edu Responses to a month of mail
C00259 00039 ∂28-Jun-89 0940 @mc.lcs.mit.edu:mkatz@sesame.stanford.edu Responses to responses to responses
C00265 00040 ∂28-Jun-89 1125 @mc.lcs.mit.edu,@ZURICH.ai.mit.edu:mkatz@sesame.stanford.edu Declare proposal
C00268 00041 ∂28-Jun-89 1345 @mc.lcs.mit.edu,@relay.cs.net,@tektronix.tek.com:kend@bloom.la.tek.com Re: A month of mail...
C00273 00042 ∂28-Jun-89 2147 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #148
C00276 00043 ∂28-Jun-89 2257 @mc.lcs.mit.edu:shap@sid.stanford.edu A month of mail...
C00279 00044 ∂29-Jun-89 0533 @mc.lcs.mit.edu,@mbunix.mitre.org:ramsdell@linus.mitre.org Make the semantics of internal and external definitions identical
C00282 00045 ∂29-Jun-89 0956 @MC.lcs.mit.edu:Alan@REAGAN.ai.mit.edu Responses to a month of mail
C00288 00046 ∂29-Jun-89 1254 @mc.lcs.mit.edu,@relay.cs.net,@tektronix.tek.com:kend@bloom.la.tek.com Re: A month of mail...
C00292 00047 ∂29-Jun-89 1434 @mc.lcs.mit.edu,@relay.cs.net,@tektronix.tek.com:kend@bloom.la.tek.com Re: Responses to a month of mail
C00297 00048 ∂29-Jun-89 2112 @mc.lcs.mit.edu,@mojave.stanford.edu:shap@sid.stanford.edu A month of mail...
C00303 00049 ∂29-Jun-89 2129 @mc.lcs.mit.edu,@relay.cs.net,@mojave.stanford.edu:shap@sid.stanford.edu A month of mail...
C00305 00050 ∂30-Jun-89 1052 @mc.lcs.mit.edu:chaynes@iuvax.cs.indiana.edu Draft agenda for 3rd IEEE Scheme standard meeting
C00308 00051 ∂30-Jun-89 1229 @mc.lcs.mit.edu:jinx@ZURICH.ai.mit.edu Location for 3rd IEEE Scheme standard meeting
C00310 00052 ∂30-Jun-89 1535 @mc.lcs.mit.edu,@relay.cs.net,@tektronix.tek.com:kend@tekchips.labs.tek.com R↑3.95RS: open-input-file open-output-file
C00314 00053 ∂30-Jun-89 2123 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #149
C00319 00054 ∂01-Jul-89 0447 @mc.lcs.mit.edu:jinx@ZURICH.ai.mit.edu R↑3.95RS: open-input-file open-output-file
C00324 00055 ∂01-Jul-89 2126 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #150
C00326 00056 ∂02-Jul-89 1434 @mc.lcs.mit.edu,@mojave.stanford.edu:shap@sid.stanford.edu R↑3.95RS: open-input-file open-output-file
C00330 00057 ∂02-Jul-89 2200 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #151
C00359 00058 ∂03-Jul-89 2219 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #152
C00382 00059 ∂04-Jul-89 1707 @mc.lcs.mit.edu,@relay.cs.net,@tektronix.tek.com:kend@bloom.la.tek.com R↑3.95RS: open-input-file open-output-file
C00386 00060 ∂05-Jul-89 1411 @mc.lcs.mit.edu,@decwrl.pa.dec.com:jmiller@crl.dec.com Responses to a month of mail
C00389 00061 ∂05-Jul-89 1452 @mc.lcs.mit.edu,@decwrl.pa.dec.com:jmiller@crl.dec.com R↑3.95RS: open-input-file open-output-file
C00392 00062 ∂05-Jul-89 1835 @mc.lcs.mit.edu:Pavel.pa@xerox.com Re: R↑3.95RS: open-input-file open-output-file
C00395 00063 ∂05-Jul-89 1856 @mc.lcs.mit.edu:Pavel.pa@xerox.com Curried definition syntax
C00397 00064 ∂05-Jul-89 1919 @mc.lcs.mit.edu:Pavel.pa@xerox.com Uniform definition semantics
C00403 00065 ∂05-Jul-89 1941 @mc.lcs.mit.edu:Pavel.pa@xerox.com Reserving a character for experimentation
C00409 00066 ∂05-Jul-89 2048 @mc.lcs.mit.edu:Pavel.pa@xerox.com Assignment to standard variables
C00420 00067 ∂05-Jul-89 2227 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #153
C00427 00068 ∂05-Jul-89 2230 @mc.lcs.mit.edu:Pavel.pa@xerox.com Fluid binding
C00438 00069 ∂05-Jul-89 2240 @mc.lcs.mit.edu:jinx@ZURICH.ai.mit.edu Assignment to standard variables
C00452 00070 ∂06-Jul-89 0713 @MC.lcs.mit.edu:jmiller@crl.dec.com Reserving a character for experimentation
C00456 00071 ∂06-Jul-89 0730 @MC.lcs.mit.edu:sfk@hplb.hpl.hp.com Re: Fluid binding
C00462 00072 ∂06-Jul-89 0843 @mc.lcs.mit.edu:jinx@ZURICH.ai.mit.edu Fluid binding
C00465 00073 ∂06-Jul-89 1012 @mc.lcs.mit.edu:mkatz@sesame.stanford.edu Assignment to standard variables
C00480 00074 ∂06-Jul-89 1035 @mc.lcs.mit.edu:mkatz@sesame.stanford.edu Fluid binding
C00493 00075 ∂06-Jul-89 1043 @mc.lcs.mit.edu:mkatz@sesame.stanford.edu Fluid binding
C00501 00076 ∂06-Jul-89 1058 @MC.lcs.mit.edu:jinx@ZURICH.ai.mit.edu Fluid binding
C00508 00077 ∂06-Jul-89 1637 @mc.lcs.mit.edu,@ZURICH.ai.mit.edu:ramsdell@linus.mitre.org An International Character Set for R4RS
C00511 00078 ∂06-Jul-89 1902 @mc.lcs.mit.edu:Pavel.pa@xerox.com Re: Assignment to standard variables
C00513 00079 ∂06-Jul-89 2228 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #154
C00545 00080 ∂07-Jul-89 1700 @mc.lcs.mit.edu:Pavel.pa@xerox.com Re: Reserving a character for experimentation
C00550 00081 ∂07-Jul-89 1740 @mc.lcs.mit.edu,@ti.com:bartley@m2.csc.ti.com Responses to a month of mail
C00554 00082 ∂08-Jul-89 1717 @mc.lcs.mit.edu,@sonoma.stanford.edu:shap@annabel.stanford.edu Fluid binding
C00557 00083 ∂08-Jul-89 1732 @mc.lcs.mit.edu,@sonoma.stanford.edu:shap@annabel.stanford.edu Assignment to standard variables
C00563 00084 ∂08-Jul-89 1751 @mc.lcs.mit.edu,@sonoma.stanford.edu:shap@annabel.stanford.edu Reserving a character for experimentation
C00566 00085 ∂08-Jul-89 2224 @mc.lcs.mit.edu:jinx@ZURICH.ai.mit.edu Fluid binding
C00570 00086 ∂09-Jul-89 2121 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #155
C00573 00087 ∂10-Jul-89 1447 @MC.lcs.mit.edu:Alan@REAGAN.ai.mit.edu R↑3.95RS: open-input-file open-output-file
C00576 00088 ∂10-Jul-89 2055 @mc.lcs.mit.edu,@decwrl.dec.com:jmiller@crl.dec.com LIST-REF, revisited
C00580 00089 ∂11-Jul-89 0857 @mc.lcs.mit.edu,@ZURICH.ai.mit.edu:ramsdell@linus.mitre.org International character sets.
C00600 00090 ∂11-Jul-89 0951 @mc.lcs.mit.edu,@ZURICH.ai.mit.edu:mkatz@sesame.stanford.edu Regularization of list, vector, and string procedures
C00613 00091 ∂11-Jul-89 1100 @MC.lcs.mit.edu,@mojave.stanford.edu:shap@sid.stanford.edu Fluid binding
C00615 00092 ∂11-Jul-89 1105 @MC.lcs.mit.edu,@ZURICH.ai.mit.edu:shap@sid.stanford.edu International character sets.
C00618 00093 ∂11-Jul-89 1136 @mc.lcs.mit.edu,@ZURICH.ai.mit.edu:jar@annabel.stanford.edu Regularization of list, vector, and string procedures
C00622 00094 ∂11-Jul-89 2148 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #156
C00624 00095 ∂12-Jul-89 1325 @mc.lcs.mit.edu:Pavel.pa@xerox.com Fluid binding
C00635 00096 ∂12-Jul-89 1400 @mc.lcs.mit.edu,@LIFE.ai.mit.edu:cph@zurich.ai.mit.edu scheme mailing list
C00639 00097 ∂12-Jul-89 1433 @mc.lcs.mit.edu,@decwrl.dec.com:jmiller@crl.dec.com R↑3.95RS: open-input-file open-output-file
C00643 00098 ∂12-Jul-89 1444 @mc.lcs.mit.edu,@decwrl.dec.com:jmiller@crl.dec.com EQV? and =
C00646 00099 ∂12-Jul-89 1716 @mc.lcs.mit.edu,@life.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu last call: changes for R4RS
C00655 00100 ∂12-Jul-89 1731 @mc.lcs.mit.edu,@life.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu legion
C00667 00101 ∂12-Jul-89 1745 @mc.lcs.mit.edu,@life.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu Regularization of list, vector, and string procedures
C00676 00102 ∂12-Jul-89 2216 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #157
C00688 00103 ∂13-Jul-89 0537 @mc.lcs.mit.edu,@life.ai.mit.edu:ramsdell@linus.mitre.org fluid variables
C00691 00104 ∂13-Jul-89 1137 @mc.lcs.mit.edu,@life.ai.mit.edu:mkatz@sesame.stanford.edu last call: changes for R4RS
C00695 00105 ∂13-Jul-89 1141 @mc.lcs.mit.edu,@life.ai.mit.edu:mkatz@sesame.stanford.edu Regularization of list, vector, and string procedures
C00705 00106 ∂13-Jul-89 1156 @mc.lcs.mit.edu,@life.ai.mit.edu:gls@think.com last call: changes for R4RS
C00712 00107 ∂13-Jul-89 1202 @mc.lcs.mit.edu,@life.ai.mit.edu:Alan@REAGAN.ai.mit.edu legion
C00718 00108 ∂13-Jul-89 1233 @mc.lcs.mit.edu,@life.ai.mit.edu:gls@think.com Correction
C00721 00109 ∂13-Jul-89 1238 @mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com Fluid binding
C00733 00110 ∂13-Jul-89 1446 @mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu last call: changes for R4RS
C00738 00111 ∂13-Jul-89 1520 @mc.lcs.mit.edu,@life.ai.mit.edu:gls@think.com last call: changes for R4RS
C00744 00112 ∂13-Jul-89 1537 @mc.lcs.mit.edu,@LIFE.ai.mit.edu:gjs@hpesogg.hp.com last call: changes for R4RS
C00747 00113 ∂13-Jul-89 1622 @mc.lcs.mit.edu,@life.ai.mit.edu:shaff@sesame.stanford.edu last call: changes for R4RS
C00750 00114 ∂13-Jul-89 1635 @mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com Confusion
C00757 00115 ∂13-Jul-89 1721 @mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu last call: changes for R4RS
C00760 00116 ∂13-Jul-89 1726 @mc.lcs.mit.edu,@life.ai.mit.edu:shaff@sesame.stanford.edu last call: changes for R4RS
C00764 00117 ∂13-Jul-89 1734 @mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com Re: evaluation order
C00767 00118 ∂13-Jul-89 1747 @mc.lcs.mit.edu,@LIFE.ai.mit.edu:jinx@hpesogg.hp.com last call: changes for R4RS
C00771 00119 ∂13-Jul-89 1756 @mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@relay.cs.net,@tektronix.tek.com:kend@bloom.la.tek.com Re: last call: changes for R4RS
C00775 00120 ∂13-Jul-89 1812 @mc.lcs.mit.edu,@life.ai.mit.edu:andy@ads.com Arg evaluation order
C00780 00121 ∂13-Jul-89 1820 @mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com Arg evaluation order
C00785 00122 ∂13-Jul-89 1925 @mc.lcs.mit.edu,@life.ai.mit.edu:andy@ads.com Re: Arg evaluation order
C00793 00123 ∂13-Jul-89 2140 @mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com Arg evaluation order
C00800 00124 ∂13-Jul-89 2211 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #158
C00804 00125 ∂14-Jul-89 0433 @mc.lcs.mit.edu,@life.ai.mit.edu:gjs@hpesogg.hp.com D. Press, Ing.
C00811 00126 ∂14-Jul-89 0903 @mc.lcs.mit.edu,@life.ai.mit.edu:shaff@sesame.stanford.edu Released Report
C00814 00127 ∂15-Jul-89 0907 @mc.lcs.mit.edu,@life.ai.mit.edu:shaff@sesame.stanford.edu Released Report
C00817 00128 ∂15-Jul-89 0933 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #159
C00820 00129 ∂15-Jul-89 1102 @mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com Arg evaluation order
C00826 00130 ∂15-Jul-89 1210 @mc.lcs.mit.edu,@LIFE.ai.mit.edu:gls@think.com [postmaster@ames.UUCP: Returned mail: User unknown]
C00836 00131 ∂15-Jul-89 1217 @mc.lcs.mit.edu:chaynes@iuvax.cs.indiana.edu Minutes of the 3rd IEEE Scheme Working Group meeting
C00847 00132 ∂15-Jul-89 1323 @mc.lcs.mit.edu,@life.ai.mit.edu:shaff@sesame.stanford.edu Force & Delay manual reorganization
C00850 00133 ∂15-Jul-89 1328 @mc.lcs.mit.edu,@life.ai.mit.edu:shaff@sesame.stanford.edu Distinct types for continuations?
C00853 00134 ∂15-Jul-89 2255 @mc.lcs.mit.edu,@LIFE.ai.mit.edu:shaff@sesame.stanford.edu Arg evaluation order
C00856 00135 ∂15-Jul-89 2315 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #160
C00868 00136 ∂16-Jul-89 1000 @mc.lcs.mit.edu,@decwrl.dec.com:jmiller@crl.dec.com [Scheme-Request@mc.lcs.mit.edu: Scheme Digest #158]
C00872 00137 ∂16-Jul-89 1341 @mc.lcs.mit.edu,@life.ai.mit.edu:danvy@freja.diku.dk Re: Distinct types for continuations?
C00876 00138 ∂16-Jul-89 2144 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #161
C00900 00139 ∂17-Jul-89 0910 @mc.lcs.mit.edu,@gateway.think.com:gls@think.com [gls@Think.COM: [postmaster@ames.UUCP: Returned mail: User unknown]]
C00910 00140 ∂17-Jul-89 1059 @mc.lcs.mit.edu,@life.ai.mit.edu:gls@think.com [gls@Think.COM: [postmaster@ames.UUCP: Returned mail: User unknown]]
C00920 00141 ∂17-Jul-89 1337 @mc.lcs.mit.edu,@life.ai.mit.edu:shaff@sesame.stanford.edu Distinct types for continuations?
C00923 00142 ∂17-Jul-89 1443 @mc.lcs.mit.edu:Alan@REAGAN.ai.mit.edu Numbers
C00931 00143 ∂17-Jul-89 1517 @mc.lcs.mit.edu,@life.ai.mit.edu:Alan@REAGAN.ai.mit.edu Distinct types for continuations?
C00935 00144 ∂17-Jul-89 1533 @mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu Numbers
C00941 00145 ∂17-Jul-89 1603 @MC.lcs.mit.edu,@gateway.think.com:gls@think.com Numbers
C00946 00146 ∂17-Jul-89 1757 @MC.lcs.mit.edu:Alan@REAGAN.ai.mit.edu Numbers
C00952 00147 ∂17-Jul-89 1905 @mc.lcs.mit.edu:Alan@REAGAN.ai.mit.edu Numbers
C00958 00148 ∂17-Jul-89 2126 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #162
C00961 00149 ∂18-Jul-89 0833 @mc.lcs.mit.edu,@gateway.think.com:gls@think.com Numbers
C00972 00150 ∂18-Jul-89 0901 @mc.lcs.mit.edu,@life.ai.mit.edu:mkatz@sesame.stanford.edu Distinct types for continuations?
C00977 00151 ∂18-Jul-89 0925 @mc.lcs.mit.edu,@life.ai.mit.edu:mkatz@sesame.stanford.edu ELSE in Scheme
C00981 00152 ∂18-Jul-89 1014 @mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu Numbers
C00990 00153 ∂18-Jul-89 1206 @mc.lcs.mit.edu,@gateway.think.com:gls@think.com Numbers
C00993 00154 ∂18-Jul-89 1528 cph@zurich.ai.mit.edu test message
C00994 00155 ∂18-Jul-89 2204 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #163
C00997 00156 ∂19-Jul-89 2155 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #164
C01000 00157 ∂20-Jul-89 1457 @mc.lcs.mit.edu,@ZERMATT.lcs.mit.edu:ziggy@hx.lcs.mit.edu BYTES (a.k.a. 1's and 0's)
C01004 00158 ∂20-Jul-89 1631 @mc.lcs.mit.edu,@life.ai.mit.edu:jar@sid.stanford.edu Bitwise logical operations
C01009 00159 ∂21-Jul-89 0124 @mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com Re: last call: changes for R4RS
C01013 00160 ∂21-Jul-89 0125 @mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com Re: last call: changes for R4RS
C01020 00161 ∂21-Jul-89 0342 @mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com Re: legion
C01026 00162 ∂21-Jul-89 0346 @mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com Re: Regularization of list, vector, and string procedures
C01032 00163 ∂21-Jul-89 0453 ramsdell@linus.mitre.org Priorities
C01036 00164 ∂21-Jul-89 0553 @mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com Re: ELSE in Scheme
C01039 00165 ∂21-Jul-89 0807 @mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com Re: Fluid binding
C01047 00166 ∂21-Jul-89 0812 @mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com last call: changes for R4RS
C01056 00167 ∂21-Jul-89 1019 @mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com legion
C01061 00168 ∂21-Jul-89 1220 cph@zurich.ai.mit.edu test
C01062 00169 ∂21-Jul-89 1449 @mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com Regularization of list, vector, and string procedures
C01069 00170 ∂21-Jul-89 1642 @mc.lcs.mit.edu,@life.ai.mit.edu:gls@think.com last call: changes for R4RS
C01075 00171 ∂21-Jul-89 1649 @mc.lcs.mit.edu,@life.ai.mit.edu:mkatz@sesame.stanford.edu ELSE in Scheme
C01079 00172 ∂21-Jul-89 1854 @mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu last call: changes for R4RS
C01083 00173 ∂21-Jul-89 1856 @mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com Re: Bitwise logical operations
C01085 00174 ∂21-Jul-89 2101 @mc.lcs.mit.edu,@life.ai.mit.edu:jmiller@crl.dec.com Regularization of list, vector, and string procedures
C01095 00175 ∂21-Jul-89 2104 @mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com Fluid binding
C01100 00176 ∂21-Jul-89 2316 @mc.lcs.mit.edu:Alan@REAGAN.ai.mit.edu Numbers
C01112 00177 ∂21-Jul-89 2322 @mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com Re: Fluid binding
C01116 00178 ∂21-Jul-89 2331 @mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com Regularization of list, vector, and string procedures
C01122 00179 ∂23-Jul-89 0001 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #167
C01125 00180 ∂24-Jul-89 0904 @mc.lcs.mit.edu,@gateway.think.com:gls@think.com Numbers
C01131 00181 ∂24-Jul-89 0945 @mc.lcs.mit.edu,@life.ai.mit.edu:mkatz@sesame.stanford.edu Regularization of list, vector, and string procedures
C01137 00182 ∂24-Jul-89 0948 @mc.lcs.mit.edu:mkatz@sesame.stanford.edu Regularization of list, vector, and string procedures
C01141 00183 ∂24-Jul-89 1216 @mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@relay.cs.net,@tektronix.tek.com:kend@mrloog.la.tek.com Re: Regularization of apply Show of hands
C01146 00184 ∂24-Jul-89 1255 @mc.lcs.mit.edu,@life.ai.mit.edu:Alan@REAGAN.ai.mit.edu Regularization of list, vector, and string procedures
C01150 00185 ∂24-Jul-89 1549 @mc.lcs.mit.edu:Alan@REAGAN.ai.mit.edu Numbers
C01157 00186 ∂25-Jul-89 1259 @mc.lcs.mit.edu,@gateway.think.com:gls@think.com Numbers
C01163 00187 ∂25-Jul-89 1454 @mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com Regularization of apply Show of hands
C01167 00188 ∂25-Jul-89 1524 @mc.lcs.mit.edu,@life.ai.mit.edu:gls@think.com Regularization of apply Show of hands
C01172 00189 ∂25-Jul-89 1909 @mc.lcs.mit.edu,@life.ai.mit.edu:KMP@stony-brook.scrc.symbolics.com INF/SUP/MIN/MAX, LIST?/PROPER-LIST?, APPLY
C01186 00190 ∂25-Jul-89 1915 @mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com Regularization of apply (long)
C01197 00191 ∂25-Jul-89 2003 @mc.lcs.mit.edu:Alan@REAGAN.ai.mit.edu Numbers
C01201 00192 ∂26-Jul-89 0359 @mc.lcs.mit.edu,@life.ai.mit.edu:Alan@reagan.ai.mit.edu INF/SUP/MIN/MAX
C01211 00193 ∂26-Jul-89 0408 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #169
C01214 00194 ∂26-Jul-89 0617 ramsdell@linus.mitre.org INF/SUP/MIN/MAX
C01216 00195 ∂26-Jul-89 0745 wand@corwin.ccs.northeastern.edu INF/SUP/MIN/MAX
C01219 00196 ∂26-Jul-89 1103 @mc.lcs.mit.edu,@life.ai.mit.edu:gls@think.com INF/SUP/MIN/MAX
C01228 00197 ∂26-Jul-89 1119 @mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu INF/SUP/MIN/MAX
C01231 00198 ∂26-Jul-89 1122 @mc.lcs.mit.edu,@life.ai.mit.edu:gls@think.com INF/SUP/MIN/MAX follow-up
C01234 00199 ∂26-Jul-89 1215 @mc.lcs.mit.edu,@life.ai.mit.edu:KMP@stony-brook.scrc.symbolics.com INF/SUP/MIN/MAX
C01246 00200 ∂26-Jul-89 1334 @mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu INF/SUP/MIN/MAX
C01254 00201 ∂26-Jul-89 1405 @mc.lcs.mit.edu,@life.ai.mit.edu:gls@think.com INF/SUP/MIN/MAX
C01265 00202 ∂26-Jul-89 1437 @mc.lcs.mit.edu,@life.ai.mit.edu:gjs@hpesogg.hp.com INF/SUP/MIN/MAX
C01268 00203 ∂26-Jul-89 1952 @mc.lcs.mit.edu,@life.ai.mit.edu:kempf@sun.com Please Remove
C01271 00204 ∂27-Jul-89 0855 @mc.lcs.mit.edu,@life.ai.mit.edu:gls@think.com INF/SUP/MIN/MAX
C01281 00205 ∂27-Jul-89 1106 @mc.lcs.mit.edu,@life.ai.mit.edu:gls@think.com INF/SUP/MIN/MAX and correct use of time
C01286 00206 ∂27-Jul-89 1116 @mc.lcs.mit.edu,@life.ai.mit.edu:wand@corwin.ccs.northeastern.edu INF/SUP/MIN/MAX
C01301 00207 ∂27-Jul-89 1122 @mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@relay.cs.net,@tektronix.tek.com:kend@mrloog.la.tek.com Re: Regularization of apply (long)
C01307 00208 ∂27-Jul-89 1209 @mc.lcs.mit.edu,@life.ai.mit.edu:shaff@sesame.stanford.edu Multiple Values for R5RS (VERY LONG)
C01323 00209 ∂28-Jul-89 1154 @mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com Regularization of apply (long)
C01328 00210 ∂28-Jul-89 1219 @mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com INF/SUP/MIN/MAX
C01332 00211 ∂28-Jul-89 1401 @mc.lcs.mit.edu:Alan@REAGAN.ai.mit.edu Numbers
C01342 00212 ∂28-Jul-89 1635 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #170
C01356 00213 ∂28-Jul-89 1839 @mc.lcs.mit.edu,@life.ai.mit.edu:jar@sid.stanford.edu INF/SUP/MIN/MAX
C01359 00214 ∂28-Jul-89 2243 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #171
C01364 00215 ∂30-Jul-89 1023 @mc.lcs.mit.edu,@life.ai.mit.edu:jeff%aiai.edinburgh.ac.uk@nsfnet-relay.ac.uk Re: INF/SUP/MIN/MAX
C01372 00216 ∂01-Aug-89 1716 @mc.lcs.mit.edu:hieb@iuvax.cs.indiana.edu revisiting lambda*
C01383 00217 ∂01-Aug-89 1731 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #172
C01386 00218 ∂01-Aug-89 1806 @mc.lcs.mit.edu,@life.ai.mit.edu:hal@zurich.ai.mit.edu Take Two
C01388 00219 ∂01-Aug-89 1810 @mc.lcs.mit.edu,@life.ai.mit.edu:jar@sid.stanford.edu Take Two
C01392 00220 ∂02-Aug-89 0359 ramsdell@linus.mitre.org Re: Take Two
C01394 00221 ∂02-Aug-89 1357 @mc.lcs.mit.edu:dyb@iuvax.cs.indiana.edu Re: Take Two
C01396 00222 ∂06-Aug-89 1352 @mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com revisiting lambda*
C01414 00223 ∂07-Aug-89 1734 @mc.lcs.mit.edu,@LIFE.ai.mit.edu,@zurich.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu LIST?
C01420 00224 ∂07-Aug-89 1756 @mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu sequential order of evaluation
C01425 00225 ∂07-Aug-89 1949 @mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu R3.99RS issues (long message)
C01444 00226 ∂07-Aug-89 2002 @mc.lcs.mit.edu,@LIFE.ai.mit.edu,@zurich.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu MIN and MAX (long message)
C01472 00227 ∂07-Aug-89 2206 @mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu LIST?
C01475 00228 ∂07-Aug-89 2216 @mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com LIST?
C01479 00229 ∂07-Aug-89 2237 cph@zurich.ai.mit.edu Scheme Digest #174
C01483 00230 ∂08-Aug-89 0015 @mc.lcs.mit.edu,@zermatt.lcs.mit.edu:ziggy@hx.lcs.mit.edu RE: sequential evaluation of arguments
C01488 00231 ∂08-Aug-89 0241 @mc.lcs.mit.edu,@zermatt.lcs.mit.edu:jinx@hpesogg.hp.com sequential evaluation of arguments
C01492 00232 ∂08-Aug-89 0258 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #175
C01495 00233 ∂08-Aug-89 1701 @mc.lcs.mit.edu,@life.ai.mit.edu:shaff@sesame.stanford.edu R3.99RS issues (else)
C01498 00234 ∂08-Aug-89 1733 @mc.lcs.mit.edu,@life.ai.mit.edu:hudak-paul@yale.edu Re: sequential order of evaluation
C01502 00235 ∂08-Aug-89 1910 @mc.lcs.mit.edu,@life.ai.mit.edu:mkatz@sesame.stanford.edu LIST?
C01505 00236 ∂08-Aug-89 2158 @mc.lcs.mit.edu,@life.ai.mit.edu:mkatz@sesame.stanford.edu sequential order of evaluation
C01509 00237 ∂08-Aug-89 2334 @mc.lcs.mit.edu,@ZERMATT.lcs.mit.edu:RPG@sail.stanford.edu re: sequential evaluation of arguments
C01512 00238 ∂09-Aug-89 0009 @mc.lcs.mit.edu,@life.ai.mit.edu:shaff@sesame.stanford.edu R3.99RS issues (macros in R4RS)
C01516 00239 ∂09-Aug-89 0012 @mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@ZERMATT.lcs.mit.edu:ziggy@hx.lcs.mit.edu RE: evaluation order rule
C01520 00240 ∂09-Aug-89 0148 @mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com Re: R3.99RS issues (else)
C01523 00241 ∂09-Aug-89 0355 @mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com Dynamic variables
C01532 00242 ∂09-Aug-89 0440 @mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com sequential order of evaluation
C01536 00243 ∂09-Aug-89 0657 @mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com MIN and MAX (long message)
C01542 00244 ∂09-Aug-89 1545 @mc.lcs.mit.edu,@life.ai.mit.edu:bartlett@decwrl.dec.com First BASH Meeting
C01563 00245 ∂10-Aug-89 0646 @mc.lcs.mit.edu,@life.ai.mit.edu:mkatz@sesame.stanford.edu R3.99RS issues (else)
C01567 00246 ∂10-Aug-89 0717 @mc.lcs.mit.edu,@life.ai.mit.edu:mkatz@sesame.stanford.edu Dynamic variables
C01571 00247 ∂10-Aug-89 0725 @mc.lcs.mit.edu,@life.ai.mit.edu:jeff%aiai.edinburgh.ac.uk@nsfnet-relay.ac.uk No mail
C01574 00248 ∂10-Aug-89 0846 ramsdell@linus.mitre.org Re: First BASH Meeting (Let's meet at POPL)
C01578 00249 ∂10-Aug-89 0902 @mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com R3.99RS issues (macros in R4RS)
C01582 00250 ∂10-Aug-89 1246 @mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@relay.cs.net,@tektronix.tek.com:adams@tekchips.labs.tek.com Dynamic variables
C01585 00251 ∂10-Aug-89 1332 mkatz@sesame.stanford.edu First BASH Meeting (Let's meet at POPL)
C01588 00252 ∂10-Aug-89 1625 shaff@sesame.stanford.edu First BASH Meeting (macros)
C01590 00253 ∂12-Aug-89 0228 @mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu Re: Dynamic variables
C01594 00254 ∂12-Aug-89 1538 @mc.lcs.mit.edu,@life.ai.mit.edu:danvy@gang-of-four.stanford.edu Re: Dynamic variables
C01598 00255 ∂13-Aug-89 0537 @mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com Re: Dynamic variables
C01601 00256 ∂13-Aug-89 2354 @mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com Re: Dynamic variables
C01605 00257 ∂14-Aug-89 0829 @mc.lcs.mit.edu,@life.ai.mit.edu:halstead@crl.dec.com Re: Arg evaluation order
C01610 00258 ∂14-Aug-89 1634 @mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu Re: Dynamic variables
C01613 00259 ∂15-Aug-89 1812 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #177
C01622 00260 ∂20-Aug-89 1056 @mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com Programmer-defined data types
C01634 00261 ∂21-Aug-89 1359 ramsdell@linus.mitre.org Multiple values for R4RS.
C01638 00262 ∂21-Aug-89 1450 cph@zurich.ai.mit.edu Multiple values for R4RS.
C01642 00263 ∂21-Aug-89 1539 harris%hplwhh@hplabs.hp.com Re: Multiple values for R4RS.
C01648 00264 ∂21-Aug-89 1543 @mc.lcs.mit.edu,@gateway.think.com:gls@think.com Numbers
C01654 00265 ∂21-Aug-89 1652 jinx@hpesogg.hp.com Multiple values for R4RS.
C01657 00266 ∂22-Aug-89 0445 ramsdell@linus.mitre.org Re: Multiple values for R4RS.
C01664 00267 ∂22-Aug-89 1052 harris%hplwhh@hplabs.hp.com Re: Multiple values for R4RS.
C01666 00268 ∂22-Aug-89 1130 ramsdell@linus.mitre.org Re: Multiple values for R4RS.
C01671 00269 ∂22-Aug-89 1150 mkatz@sesame.stanford.edu Multiple values for R4RS.
C01673 00270 ∂22-Aug-89 1221 dyb@iuvax.cs.indiana.edu Re: Multiple values for R4RS.
C01676 00271 ∂22-Aug-89 1234 mkatz@sesame.stanford.edu Multiple values for R4RS.
C01680 00272 ∂22-Aug-89 1339 mkatz@sesame.stanford.edu Multiple values for R4RS.
C01683 00273 ∂22-Aug-89 1359 mkatz@sesame.stanford.edu Multiple values for R4RS.
C01687 00274 ∂22-Aug-89 1415 jinx@hpesogg.hp.com Multiple values for R4RS.
C01690 00275 ∂22-Aug-89 1432 jinx@hpesogg.hp.com Multiple values for R4RS.
C01694 00276 ∂22-Aug-89 1445 @relay.cs.net,@tektronix.tek.com:adams@tekchips.labs.tek.com Multiple values for R4RS.
C01698 00277 ∂22-Aug-89 1448 jinx@hpesogg.hp.com Multiple values for R4RS.
C01702 00278 ∂22-Aug-89 1606 mkatz%sesame.stanford.edu@relay.cs.net Multiple values for R4RS.
C01705 00279 ∂22-Aug-89 1634 cph@zurich.ai.mit.edu Multiple values for R4RS.
C01711 00280 ∂22-Aug-89 1713 jinx@hpesogg.hp.com Multiple values for R4RS.
C01714 00281 ∂22-Aug-89 1740 @relay.cs.net,@tektronix.tek.com:adams@tekchips.labs.tek.com Multiple values for R4RS.
C01718 00282 ∂22-Aug-89 1824 @spencer.cs.uoregon.edu:will@cs.uoregon.edu multiple values
C01722 00283 ∂22-Aug-89 1838 @spencer.cs.uoregon.edu:will@cs.uoregon.edu theology MAX and MIN
C01728 00284 ∂22-Aug-89 1842 jinx@hpesogg.hp.com Multiple values for R4RS.
C01735 00285 ∂22-Aug-89 2037 dyb@iuvax.cs.indiana.edu Re: Multiple values for R4RS.
C01738 00286 ∂22-Aug-89 2052 dyb@iuvax.cs.indiana.edu Re: Multiple values for R4RS.
C01741 00287 ∂22-Aug-89 2105 dyb@iuvax.cs.indiana.edu Re: multiple values
C01743 00288 ∂23-Aug-89 0440 jinx@hpesogg.hp.com multiple values
C01748 00289 ∂23-Aug-89 0458 ramsdell@linus.mitre.org Just add WITH-VALUES and VALUES.
C01753 00290 ∂23-Aug-89 0458 jinx@hpesogg.hp.com Multiple values for R4RS.
C01756 00291 ∂23-Aug-89 0508 jinx@hpesogg.hp.com Multiple values for R4RS.
C01762 00292 ∂23-Aug-89 0853 @mc.lcs.mit.edu,@gateway.think.com:gls@think.com Numbers
C01770 00293 ∂23-Aug-89 0856 @mc.lcs.mit.edu:bawden.pa@xerox.com Numbers
C01777 00294 ∂23-Aug-89 0905 dyb@iuvax.cs.indiana.edu Re: multiple values
C01780 00295 ∂23-Aug-89 0925 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #180
C01788 00296 ∂23-Aug-89 0939 dyb@iuvax.cs.indiana.edu Re: Multiple values for R4RS.
C01792 00297 ∂23-Aug-89 1027 mkatz%sesame.stanford.edu@relay.cs.net Multiple values for R4RS.
C01797 00298 ∂23-Aug-89 1102 cph@zurich.ai.mit.edu Multiple values for R4RS.
C01801 00299 ∂23-Aug-89 1104 KMP@stony-brook.scrc.symbolics.com Re: Multiple values for R4RS.
C01808 00300 ∂23-Aug-89 1104 mkatz@sesame.stanford.edu multiple values
C01811 00301 ∂23-Aug-89 1105 mkatz@sesame.stanford.edu multiple values
C01815 00302 ∂23-Aug-89 1118 mkatz@sesame.stanford.edu Multiple values for R4RS.
C01818 00303 ∂23-Aug-89 1118 @relay.cs.net,@tektronix.tek.com:adams@tekchips.labs.tek.com Multiple values for R4RS.
C01821 00304 ∂23-Aug-89 1126 jar@zurich.ai.mit.edu Just add WITH-VALUES and VALUES.
C01824 00305 ∂23-Aug-89 1126 jar@zurich.ai.mit.edu Just add WITH-VALUES and VALUES.
C01828 00306 ∂23-Aug-89 1134 @relay.cs.net,@tektronix.tek.com:adams@tekchips.labs.tek.com Multiple values for R4RS.
C01832 00307 ∂23-Aug-89 1200 jinx@hpesogg.hp.com Multiple values for R4RS.
C01835 00308 ∂23-Aug-89 1200 jinx@hpesogg.hp.com multiple values
C01838 00309 ∂23-Aug-89 1201 jinx@hpesogg.hp.com Just add WITH-VALUES and VALUES.
C01841 00310 ∂23-Aug-89 1203 jinx@hpesogg.hp.com Multiple values for R4RS.
C01843 00311 ∂23-Aug-89 1235 @relay.cs.net,@gateway.think.com:gls@THINK.COM Multiple values for R4RS.
C01847 00312 ∂23-Aug-89 1237 @mc.lcs.mit.edu,@gateway.think.com:gls@think.com Numbers
C01856 00313 ∂23-Aug-89 1238 jinx@hpesogg.hp.com Just add WITH-VALUES and VALUES.
C01861 00314 ∂23-Aug-89 1407 gls@think.com theology MAX and MIN
C01866 00315 ∂23-Aug-89 1407 jinx@hpesogg.hp.com Multiple values for R4RS.
C01869 00316 ∂23-Aug-89 1418 ramsdell@linus.mitre.org Amended WITH-VALUES and VALUES.
C01875 00317 ∂23-Aug-89 1502 dyb@iuvax.cs.indiana.edu Re: Multiple values for R4RS.
C01878 00318 ∂23-Aug-89 1506 @zermatt.lcs.mit.edu:ziggy@HX.LCS.MIT.EDU RE: RECORDs proposal
C01885 00319 ∂23-Aug-89 1513 jinx@hpesogg.hp.com Amended WITH-VALUES and VALUES.
C01888 00320 ∂23-Aug-89 1516 @mc.lcs.mit.edu,@life.ai.mit.edu:gls@think.com INF/SUP/MIN/MAX
C01897 00321 ∂23-Aug-89 1519 dyb@iuvax.cs.indiana.edu Re: Multiple values for R4RS.
C01899 00322 ∂23-Aug-89 1718 dyb@iuvax.cs.indiana.edu Re: multiple values
C01902 00323 ∂23-Aug-89 1759 halstead@crl.dec.com
C01909 00324 ∂23-Aug-89 1954 @mc.lcs.mit.edu,@life.ai.mit.edu:gls@think.com MIN and MAX (long message)
C01916 00325 ∂23-Aug-89 2120 @mc.lcs.mit.edu,@life.ai.mit.edu:bawden.pa@xerox.com Programmer-defined data types
C01923 00326 ∂23-Aug-89 2230 @mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@relay.cs.net,@tektronix.tek.com:adams@tekchips.labs.tek.com Programmer-defined data types
C01927 00327 ∂24-Aug-89 0210 @mc.lcs.mit.edu:bawden.pa@xerox.com Numbers and Pork Rinds
C01932 00328 ∂24-Aug-89 0323 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #186
C01940 00329 ∂24-Aug-89 0428 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #182
C01944 00330 ∂24-Aug-89 0504 ramsdell@linus.mitre.org Revised WITH-VALUES and VALUES (I think we are near agreement!)
C01949 00331 ∂24-Aug-89 0600 @mc.lcs.mit.edu:bawden.pa@xerox.com Numbers
C01954 00332 ∂24-Aug-89 0629 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #183
C01956 00333 ∂24-Aug-89 1002 cph@zurich.ai.mit.edu Revised WITH-VALUES and VALUES (I think we are near agreement!)
C01959 00334 ∂24-Aug-89 1009 gls@think.com Multiple values for R4RS.
C01963 00335 ∂24-Aug-89 1202 ramsdell@linus.mitre.org Re: Revised WITH-VALUES and VALUES (I think we are near agreement!)
C01966 00336 ∂25-Aug-89 0414 @mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu Programmer-defined data types
C01971 00337 ∂25-Aug-89 1016 @mc.lcs.mit.edu,@gateway.think.com:gls@think.com Numbers and Pork Rinds
C01981 00338 ∂25-Aug-89 1054 jinx@hpesogg.hp.com Revised WITH-VALUES and VALUES (I think we are near agreement!)
C01984 00339 ∂25-Aug-89 1151 ramsdell@linus.mitre.org Re: Revised WITH-VALUES and VALUES (I think we are near agreement!)
C01988 00340 ∂25-Aug-89 1221 jinx@hpesogg.hp.com Revised WITH-VALUES and VALUES (I think we are near agreement!)
C01990 00341 ∂25-Aug-89 1234 ramsdell@linus.mitre.org "is an error" -> "is undefined"
C01993 00342 ∂25-Aug-89 1237 KMP@stony-brook.scrc.symbolics.com Revised WITH-VALUES and VALUES (I think we are near agreement!)
C02001 00343 ∂25-Aug-89 1726 jinx@hpesogg.hp.com "is an error" -> "is undefined"
C02004 00344 ∂25-Aug-89 1749 jinx@hpesogg.hp.com Revised WITH-VALUES and VALUES (I think we are near agreement!)
C02010 00345 ∂25-Aug-89 2303 @mc.lcs.mit.edu:bawden.pa@xerox.com Numbers and Pork Rinds
C02021 00346 ∂26-Aug-89 0100 @mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@relay.cs.net,@tektronix.tek.com:adams@tekchips.labs.tek.com Programmer-defined data types
C02025 00347 ∂26-Aug-89 0315 @mc.lcs.mit.edu,@life.ai.mit.edu:KMP@stony-brook.scrc.symbolics.com Programmer-defined data types
C02040 00348 ∂26-Aug-89 0529 @mc.lcs.mit.edu:harrison@s45.csrd.uiuc.edu Numbers and Pork Rinds
C02045 00349 ∂26-Aug-89 0532 @mc.lcs.mit.edu,@hp-sde.sde.hp.com:jinx@hpesogg.hp.com Numbers
C02050 00350 ∂27-Aug-89 0028 @mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu Multiple values for R4RS
C02062 00351 ∂27-Aug-89 1443 @mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu last call for MIN and MAX
C02066 00352 ∂27-Aug-89 1647 @mc.lcs.mit.edu,@hp-sde.sde.hp.com:jinx@hpesogg.hp.com Numbers and Pork Rinds
C02071 00353 ∂27-Aug-89 1653 @mc.lcs.mit.edu:bawden@arisia.xerox.com Numbers and Pork Rinds
C02080 00354 ∂28-Aug-89 0455 ramsdell@linus.mitre.org Kent, please bless this multiple values proposal.
C02085 00355 ∂28-Aug-89 0925 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #189
C02089 00356 ∂28-Aug-89 1120 @mc.lcs.mit.edu:hieb@iuvax.cs.indiana.edu multiple values
C02094 00357 ∂28-Aug-89 1412 ramsdell@linus.mitre.org Re: multiple values
C02098 00358 ∂28-Aug-89 1619 bawden@arisia.xerox.com Re: multiple values
C02101 00359 ∂28-Aug-89 1955 @mc.lcs.mit.edu,@gateway.think.com:gls@think.com Numbers and Pork Rinds
C02105 00360 ∂28-Aug-89 2212 @mc.lcs.mit.edu:bawden@arisia.xerox.com Numbers and Pork Rinds
C02109 00361 ∂29-Aug-89 0050 @mc.lcs.mit.edu,@hp-sde.sde.hp.com:jinx@hpesogg.hp.com multiple values
C02112 00362 ∂29-Aug-89 0517 ramsdell@linus.mitre.org Re: multiple values
C02116 00363 ∂29-Aug-89 0657 ramsdell@linus.mitre.org rrrs-authors-request@life.ai.mit.edu is broken.
C02121 00364 ∂29-Aug-89 0732 @mc.lcs.mit.edu,@hp-sde.sde.hp.com:jinx@hpesogg.hp.com Numbers and Pork Rinds
C02124 00365 ∂29-Aug-89 0838 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #188
C02129 00366 ∂29-Aug-89 0915 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #190
C02132 00367 ∂29-Aug-89 1316 mkatz@sesame.stanford.edu Kent, please bless this multiple values proposal.
C02136 00368 ∂29-Aug-89 1920 @mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com Programmer-defined data types, version 2
C02153 00369 ∂30-Aug-89 0021 Pavel.pa@xerox.com Multiple values
C02159 00370 ∂30-Aug-89 0522 ramsdell@linus.mitre.org multiple values and call/cc.
C02164 00371 ∂30-Aug-89 0528 ramsdell@linus.mitre.org Re: Multiple values
C02167 00372 ∂30-Aug-89 1205 katz@polya.stanford.edu Multiple values
C02170 00373 ∂30-Aug-89 1310 ramsdell@linus.mitre.org Revised multiple values and call/cc.
C02175 00374 ∂30-Aug-89 1522 dyb@iuvax.cs.indiana.edu Re: Multiple values for R4RS
C02181 00375 ∂30-Aug-89 1802 @mc.lcs.mit.edu:hieb@iuvax.cs.indiana.edu mv continuations
C02186 00376 ∂30-Aug-89 1833 @mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com Re: Programmer-defined data types, version 2
C02190 00377 ∂30-Aug-89 2012 @mc.lcs.mit.edu,@life.ai.mit.edu:andy@ads.com Re: Programmer-defined data types, version 2
C02196 00378 ∂30-Aug-89 2042 @mc.lcs.mit.edu,@life.ai.mit.edu:katz@polya.stanford.edu Programmer-defined data types, version 2
C02200 00379 ∂31-Aug-89 0231 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #192
C02243 00380 ∂31-Aug-89 0542 ramsdell@linus.mitre.org Re: Multiple values for R4RS
C02249 00381 ∂31-Aug-89 1103 ramsdell@linus.mitre.org Multiple values not for R4RS
C02254 00382 ∂31-Aug-89 1106 dyb@iuvax.cs.indiana.edu Re: Multiple values for R4RS
C02257 00383 ∂31-Aug-89 1111 katz@polya.stanford.edu Multiple values for R4RS
C02262 00384 ∂31-Aug-89 1121 ramsdell@linus.mitre.org Re: Multiple values for R4RS
C02266 00385 ∂31-Aug-89 1134 katz@polya.stanford.edu Revised multiple values and call/cc.
C02270 00386 ∂31-Aug-89 2019 @spencer.cs.uoregon.edu:will@cs.uoregon.edu Re: Multiple values not for R4RS
C02273 00387 ∂31-Aug-89 2026 katz@polya.stanford.edu Multiple values not for R4RS
C02276 00388 ∂01-Sep-89 0001 Pavel.pa@xerox.com An alternate description of the multiple values proposal
C02283 00389 ∂01-Sep-89 0052 @mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu Programmer-defined data types, version 2
C02286 00390 ∂01-Sep-89 0054 @mc.lcs.mit.edu,@life.ai.mit.edu:jar@zurich.ai.mit.edu Programmer-defined data types, version 2
C02289 00391 ∂01-Sep-89 0259 @mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu Programmer-defined data types, version 2
C02293 00392 ∂01-Sep-89 0304 @mc.lcs.mit.edu,@life.ai.mit.edu:katz@polya.stanford.edu Programmer-defined data types, version 2
C02297 00393 ∂01-Sep-89 0333 jinx@zurich.ai.mit.edu An alternate description of the multiple values proposal
C02300 00394 ∂01-Sep-89 0544 ramsdell@linus.mitre.org Please rename BABY-DOE and agree on an agenda item
C02306 00395 ∂01-Sep-89 0610 ramsdell@linus.mitre.org Re: Multiple values not for R4RS
C02310 00396 ∂01-Sep-89 0623 ramsdell@linus.mitre.org Re: An alternate description of the multiple values proposal
C02314 00397 ∂01-Sep-89 0757 ramsdell@linus.mitre.org An alternative to ACCEPTS?
C02317 00398 ∂01-Sep-89 0900 @mc.lcs.mit.edu,@life.ai.mit.edu:katz@polya.stanford.edu Programmer-defined data types, version 2
C02322 00399 ∂01-Sep-89 0909 katz@polya.stanford.edu Multiple values not for R4RS
C02326 00400 ∂01-Sep-89 0914 katz@polya.stanford.edu An alternative to ACCEPTS?
C02330 00401 ∂01-Sep-89 0949 ramsdell@linus.mitre.org Re: Multiple values not for R4RS
C02333 00402 ∂01-Sep-89 1050 Pavel.pa@xerox.com Re: An alternate description of the multiple values proposal
C02339 00403 ∂01-Sep-89 1404 cph@zurich.ai.mit.edu An alternate description of the multiple values proposal
C02341 00404 ∂01-Sep-89 1419 cph@zurich.ai.mit.edu An alternate description of the multiple values proposal
C02345 00405 ∂01-Sep-89 1505 Pavel.pa@xerox.com Re: An alternate description of the multiple values proposal
C02349 00406 ∂01-Sep-89 1507 jinx@zurich.ai.mit.edu An alternate description of the multiple values proposal
C02353 00407 ∂01-Sep-89 1516 cph@zurich.ai.mit.edu An alternate description of the multiple values proposal
C02357 00408 ∂01-Sep-89 1635 Pavel.pa@xerox.com Re: An alternate description of the multiple values proposal
C02359 00409 ∂01-Sep-89 1653 @mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu Programmer-defined data types, version 2
C02364 00410 ∂01-Sep-89 1857 @mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com Programmer-defined data types, last (?) version
C02377 00411 ∂05-Sep-89 0916 ramsdell@linus.mitre.org Name for BABY-DOE should not include "values".
C02380 00412 ∂05-Sep-89 0918 ramsdell@linus.mitre.org Re: An alternate description of the multiple values proposal
C02384 00413 ∂05-Sep-89 1446 @mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@relay.cs.net:jmiller@cs.brandeis.edu Programmer-defined data types, last (?) version
C02388 00414 ∂05-Sep-89 2222 Pavel.pa@xerox.com Re: Name for BABY-DOE should not include "values".
C02391 00415 ∂05-Sep-89 2349 @mc.lcs.mit.edu,@life.ai.mit.edu:bawden@arisia.xerox.com Programmer-defined data types, last (?) version
C02396 00416 ∂06-Sep-89 0006 KMP@stony-brook.scrc.symbolics.com Baby-Doe and friends
C02403 00417 ∂06-Sep-89 0626 ramsdell@linus.mitre.org Re: Baby-Doe and friends
C02408 00418 ∂06-Sep-89 0821 gls@think.com Baby-Doe and friends
C02412 00419 ∂06-Sep-89 0859 katz@neon.stanford.edu Baby-Doe and friends
C02414 00420 ∂06-Sep-89 1018 @mc.lcs.mit.edu:hieb@iuvax.cs.indiana.edu mutiple values, procedures and continuations
C02418 00421 ∂06-Sep-89 1428 @mc.lcs.mit.edu,@life.ai.mit.edu:bawden@arisia.xerox.com Baby-Doe and friends
C02423 00422 ∂06-Sep-89 1619 @mc.lcs.mit.edu,@life.ai.mit.edu:jinx@zurich.ai.mit.edu Baby-Doe and friends
C02426 00423 ∂07-Sep-89 0942 @mc.lcs.mit.edu,@ZERMATT.lcs.mit.edu:ziggy@hx.lcs.mit.edu RE: name for VALUES
C02429 00424 ∂07-Sep-89 1013 @mc.lcs.mit.edu,@life.ai.mit.edu:jar@zurich.ai.mit.edu Baby-Doe and friends
C02432 00425 ∂08-Sep-89 0426 ramsdell@linus.mitre.org ARGUMENTS/VALUES -> CONSUME/PRODUCE
C02436 00426 ∂08-Sep-89 1024 @relay.cs.net,@tektronix.tek.com:adams@tekchips.labs.tek.com ARGUMENTS/VALUES -> CONSUME/PRODUCE
C02439 00427 ∂08-Sep-89 1318 KMP@stony-brook.scrc.symbolics.com ARGUMENTS/VALUES -> CONSUME/PRODUCE
C02444 00428 ∂08-Sep-89 1329 @mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu Baby-Doe and friends
C02447 00429 ∂08-Sep-89 1426 gls@think.com ARGUMENTS/VALUES -> CONSUME/PRODUCE
C02451 00430 ∂08-Sep-89 1542 @relay.cs.net,@tektronix.tek.com:adams@tekchips.labs.tek.com name that baby
C02455 00431 ∂08-Sep-89 1759 KMP@stony-brook.scrc.symbolics.com name that baby
C02457 00432 ∂11-Sep-89 0516 ramsdell@linus.mitre.org PIPE/CONTINUE
C02460 00433 ∂11-Sep-89 0940 katz@neon.stanford.edu ARGUMENTS/VALUES -> CONSUME/PRODUCE
C02463 00434 ∂17-Sep-89 0101 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #205
C02467 00435 ∂17-Sep-89 0157 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #200
C02474 00436 ∂17-Sep-89 0321 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #204
C02477 00437 ∂17-Sep-89 0410 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #199
C02480 00438 ∂17-Sep-89 0412 @relay.cs.net,@tektronix.tek.com:kend@mrloog.wr.tek.com DOE-SEE-DOE and HEY-BABY!
C02483 00439 ∂17-Sep-89 0413 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #203
C02489 00440 ∂21-Sep-89 0400 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #206
C02500 00441 ∂21-Sep-89 1251 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #208
C02509 00442 ∂22-Sep-89 0517 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #209
C02512 00443 ∂28-Sep-89 1124 ramsdell@linus.mitre.org Naming BABY-DOE
C02515 00444 ∂28-Sep-89 1238 @relay.cs.net,@tektronix.tek.com:adams@tekchips.labs.tek.com Naming BABY-DOE oportunistically
C02517 00445 ∂29-Sep-89 0350 ramsdell@linus.mitre.org Re: Naming BABY-DOE
C02520 00446 ∂29-Sep-89 0418 ramsdell@linus.mitre.org Re: Naming BABY-DOE
C02523 00447 ∂29-Sep-89 1610 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #214
C02527 00448 ∂29-Sep-89 2236 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #215
C02538 00449 ∂04-Oct-89 1545 KMP@stony-brook.scrc.symbolics.com Re: Naming BABY-DOE
C02550 00450 ∂07-Oct-89 0654 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #221
C02553 00451 ∂11-Oct-89 2309 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #223
C02557 00452 ∂12-Oct-89 2201 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #224
C02560 ENDMK
C⊗;
∂17-Jun-89 2139 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #139
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 17 Jun 89 21:39:33 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa00495;
18 Jun 89 0:30 EDT
Date: 18 JUN 89 00:04:06 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #139
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID: <8906180030.aa00495@mintaka.lcs.mit.edu>
Scheme Digest #139 18 JUN 89 00:04:06 EDT
Today's Topics:
BUG IN EXPANDED MEMORY TI PC-SCHEME?
----------------------------------------------------------------------
Date: 16 Jun 89 21:43:25 GMT
From: Brian Leverich <leverich@RAND.ORG>
Subject: BUG IN EXPANDED MEMORY TI PC-SCHEME?
Message-Id: <2102@randvax.UUCP>
On "long" simulation runs (20+ minutes on a 12mHz 286 with LIM 4.0 EMS...)
using PCSEXP, the _expanded memory_ version of Texas Instrument's
PC-Scheme, I apparently run low on space, the gc starts thrashing around,
and finally I get a Scheme reset because the system is out of space.
Problem is, I can't find anywhere near enough current structures to
fill memory. Moreover, (freesp) returns 400K + of memory, then if I
invoke (freesp) again (or anything else...) it triggers another gc
and sometimes another Scheme reset. I don't have the problem when I
use PCSEXT and jumper my expanded memory to act like extended. Looks
like (freesp) can see a big chunk of free space, but the gc isn't
adding it to the free list.
Anyone else had this problem with PCSEXP? Anyone have any workaround
suggestions? Tnx. -B
--
"Simulate it in ROSS"
Brian Leverich | U.S. Snail: 1700 Main St.
ARPAnet: leverich@rand.org | Santa Monica, CA 90406
UUCP: decvax!randvax!leverich | Ma Bell: (213) 393-0411 X7769
------------------------------
End of Scheme Digest
********************
∂18-Jun-89 2215 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #140
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 18 Jun 89 22:15:10 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22536;
19 Jun 89 1:05 EDT
Date: 19 JUN 89 00:06:11 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #140
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID: <8906190105.aa22536@mintaka.lcs.mit.edu>
Scheme Digest #140 19 JUN 89 00:06:11 EDT
Today's Topics:
"unspecified" and SET!
----------------------------------------------------------------------
Date: 18 Jun 89 23:17:50 GMT
From: Dorai Sitaram <titan!dorai@rice.edu>
Subject: "unspecified" and SET!
Message-Id: <3902@kalliope.rice.edu>
The recent discussion of "unspecified" values reveals that Scheme is
not as syntactically uniform as it is claimed to be. Some Scheme
syntactic forms return meaningful values, others don't: the former are
"expressions" and the latter "commands". "Commands" are usually used
to represent side-effects, e.g., assignment in the form of set!. In
an expression-oriented language, a "command" is awkwardly "expressed"
by an expression returning an arbitrary "unspecified" value.
Perhaps, SET! is not the ideal side-effecting construct for an
expression-oriented language. Felleisen and Friedman [1] propose a
side-effecting construct called a SIGMA-capability. This looks just
like a LAMBDA-expression, but whereas LAMBDA introduces new bound
variables, SIGMA modifies the binding of existing lexical variables.
In other words, on applying a SIGMA-capability to arguments, the
variables corresponding to the SIGMA-parameters are side-effected.
Problems about "unspecified" return values disappear. The application
of a SIGMA-capability side-effects the SIGMA-parameters and returns
the result of evaluating the SIGMA-body (the parallel being the
application of a LAMBDA-expression). In addition, SIGMA gives a very
natural method for parallel assignment, since the arguments to a
SIGMA-capability are all evaluated before the application performs the
side-effects.
We can retrieve the old SET! from SIGMA as follows:
(set! x a) == ((sigma (x) <what-now>) a)
where <what-now> is the "unspecified" value of your choice. Thus,
there is no dependence on a system-chosen unspecified value.
Even better, we need not fall back on a command with its necessarily
arbitrary choice of unspecified return value. We can define a
_generalized_ SET! in terms of SIGMA that is more along the lines of
LET in terms of LAMBDA:
(set! ([x a] ...) e ...) == ((sigma (x ...) e ...) a ...)
The upshot of all this is that while we have side-effects, we still
have a syntactically uniform language.
--dorai
[1] Felleisen & Friedman, A calculus for assigments ..., POPL 1987,
314 - 325.
ps: In terms of SET!, SIGMA's effect is as follows:
(sigma (x ...) e ...) == (lambda (x↑ ...) (set! x x↑) ... e ...)
where x↑ ... are new variables, used only to show what's going on. A
native implementation of SIGMA is simply got by mimicking LAMBDA,
except for the following: where LAMBDA has extend-environment, SIGMA
has update-environment.
-------------------------------------------------------------------------------
It may be that the gulfs will wash us down;
It may be we shall touch the Happy Isles.
-------------------------------------------------------------------------------
------------------------------
End of Scheme Digest
********************
∂19-Jun-89 1414 @mc.lcs.mit.edu:mkatz@sesame.stanford.edu another change for R4RS; peek-char
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 19 Jun 89 14:14:15 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa04503;
19 Jun 89 16:44 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 19 Jun 89 16:42:22 EDT
Received: from Sesame.Stanford.EDU by mintaka.lcs.mit.edu id aa18914;
19 Jun 89 12:56 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA09188; Mon, 19 Jun 89 09:55:15 PDT
Date: Mon, 19 Jun 89 09:55:15 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8906191655.AA09188@sesame.Stanford.EDU>
To: cph@zurich.ai.mit.edu
Cc: will@fog.cs.uoregon.edu, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Chris Hanson's message of Fri, 2 Jun 89 15:15:37 edt <8906021915.AA02759@ZURICH.AI.MIT.EDU>
Subject: another change for R4RS; peek-char
Date: Fri, 2 Jun 89 15:15:37 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
Reply-To: cph@zurich.ai.mit.edu
Date: Tue, 30 May 89 17:08:52 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
One person has objected, strongly, to making list-ref and list-tail
essential. Does anyone wish to counter by explaining just why it
is essential that these procedures be essential?
The reason is the following (extracted from the Working Group on
Scheme's unapproved minutes of the Feb. 3 meeting):
6.1 Procedures to be deleted from the standard.
Moved, seconded, and approved: keep LIST-REF, LIST-TAIL, and
SUBSTRING, and delete STRING->LIST, LIST->STRING, STRING-COPY,
STRING-FILL!, VECTOR->LIST, LIST->VECTOR, and VECTOR-FILL!. Since
LIST-REF and LIST-TAIL are non-essential features in R4RS, we need the
author's agreement to change them to essential.
This is required because the Working Group does not wish to
standardize on anything that is inessential in R*RS. If R*RS decides
to keep these procedures inessential, the WG will be forced to drop
them from the standard.
I suppose this can be thought of as a strong recommendation from the
WG to R*RS that it is desirable to keep these procedures.
In the original discussions on standardization, a concern was expressed that
the standards effort would try to foist changes on the R*RS community. We were
assured that this was not the case and any changes to R*RS would be made on
their own merits. I hope this position has not changed already!!! It is the
Working Groups decision to create a standard which only includes essential
features from R*RS. This decision should have not standing in R*RS
discussions.
Morry Katz
katz@polya.stanford.edu
∂19-Jun-89 1851 @mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu another change for R4RS; peek-char
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 19 Jun 89 18:51:09 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa29683;
19 Jun 89 20:04 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 19 Jun 89 19:58:15 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa12030;
19 Jun 89 19:46 EDT
Received: from ZURICH.AI.MIT.EDU ([18.43.0.172]) by life.ai.mit.edu (4.0/AI-4.10) id AA04980; Mon, 19 Jun 89 19:46:07 EDT
Return-Path: <cph@ZURICH.AI.MIT.EDU>
Received: by ZURICH.AI.MIT.EDU; Mon, 19 Jun 89 19:43:16 edt
Date: Mon, 19 Jun 89 19:43:16 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
Message-Id: <8906192343.AA23241@ZURICH.AI.MIT.EDU>
To: mkatz@sesame.stanford.edu
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Morris Katz's message of Mon, 19 Jun 89 14:52:57 PDT <8906192152.AA10258@sesame.Stanford.EDU>
Subject: another change for R4RS; peek-char
Date: Mon, 19 Jun 89 14:52:57 PDT
From: mkatz@sesame.stanford.edu (Morris Katz)
Maybe I reacted too strongly to this request, and I apologize to all if I did.
However, it is my opinion that a change is being advocated to R*RS based on no
technical arguments, but only political ones. At Snowbird, there were those of
us who advocated removing the functions in question from R*RS altogether and
others who wanted to make them essential. We reached a compromise that these
functions would remain inessential. I am afraid that if the question is
phrased in such a way that essential status and elimination become the only
viable alternatives, I will be forced to also break the truce and crusade for
elimination.
Again, the issue is much simpler than you are making out.
From the point of view of R*RS, the possible options are the same as
they were at Snowbird. Indeed, it entirely reasonable for the authors
group to take the position that there is no reason to change the
status quo. In that case, by decisions independent of R*RS, the
Scheme standard will *not* contain `list-ref' and `list-tail', but the
R*RS will still contain them as inessential procedures.
Let me reiterate: no one is reducing the authors' possible
alternatives or attempting to force a choice in any way.
The point of the request is that the standardization Working Group
feels that it is desirable to include these procedures in the
standard. Inclusion of the procedures requires that they be essential
in R*RS, because of the intention to make the standard a conservative
subset of R*RS. So the Working Group is asking the authors to
reconsider their decision in light of this situation, feeling that
perhaps the tide of opinion within the authors' community might shift.
A parting shot: your comment regarding technical vs. political
arguments is misleading. The comment attempts to make the (partially)
political argument of the Working Group appear unworthy of serious
consideration by the implication that previous arguments have
technical merit. As I understand it, there are few or no technical
arguments on either side of this issue; the arguments are primarily
aesthetic and/or practical. If there was a cogent technical reason
for doing things one way or the other, I suspect there would be wider
agreement about the status of these procedures.
∂19-Jun-89 1852 @mc.lcs.mit.edu:mkatz@sesame.stanford.edu another change for R4RS; peek-char
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 19 Jun 89 18:52:00 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa00281;
19 Jun 89 20:39 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 19 Jun 89 20:37:24 EDT
Received: from Sesame.Stanford.EDU by mintaka.lcs.mit.edu id aa29962;
19 Jun 89 20:24 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA10742; Mon, 19 Jun 89 17:19:51 PDT
Date: Mon, 19 Jun 89 17:19:51 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8906200019.AA10742@sesame.Stanford.EDU>
To: cph@zurich.ai.mit.edu
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Chris Hanson's message of Mon, 19 Jun 89 19:43:16 edt <8906192343.AA23241@ZURICH.AI.MIT.EDU>
Subject: another change for R4RS; peek-char
Date: Mon, 19 Jun 89 19:43:16 edt
From: cph@ZURICH.AI.MIT.EDU (Chris Hanson)
Date: Mon, 19 Jun 89 14:52:57 PDT
From: mkatz@sesame.stanford.edu (Morris Katz)
Maybe I reacted too strongly to this request, and I apologize to all if I did.
However, it is my opinion that a change is being advocated to R*RS based on no
technical arguments, but only political ones. At Snowbird, there were those of
us who advocated removing the functions in question from R*RS altogether and
others who wanted to make them essential. We reached a compromise that these
functions would remain inessential. I am afraid that if the question is
phrased in such a way that essential status and elimination become the only
viable alternatives, I will be forced to also break the truce and crusade for
elimination.
Again, the issue is much simpler than you are making out.
>From the point of view of R*RS, the possible options are the same as
they were at Snowbird. Indeed, it entirely reasonable for the authors
group to take the position that there is no reason to change the
status quo. In that case, by decisions independent of R*RS, the
Scheme standard will *not* contain `list-ref' and `list-tail', but the
R*RS will still contain them as inessential procedures.
Let me reiterate: no one is reducing the authors' possible
alternatives or attempting to force a choice in any way.
The point of the request is that the standardization Working Group
feels that it is desirable to include these procedures in the
standard. Inclusion of the procedures requires that they be essential
in R*RS, because of the intention to make the standard a conservative
subset of R*RS. So the Working Group is asking the authors to
reconsider their decision in light of this situation, feeling that
perhaps the tide of opinion within the authors' community might shift.
A parting shot: your comment regarding technical vs. political
arguments is misleading. The comment attempts to make the (partially)
political argument of the Working Group appear unworthy of serious
consideration by the implication that previous arguments have
technical merit. As I understand it, there are few or no technical
arguments on either side of this issue; the arguments are primarily
aesthetic and/or practical. If there was a cogent technical reason
for doing things one way or the other, I suspect there would be wider
agreement about the status of these procedures.
Let me attempt a short and cogent argument. It has always been my impression
that the Scheme community is attempting to create a small, but powerful, core
language on which real systems can be built. For our failure to include in
R*RS many useful functions that are easily implementable using the core
language, we have often been criticized by proponents of CommonLisp. I have
always believed that the Scheme approach was correct; however, it is my
personal opinion that if we are going to make list-tail and list-ref essential
then there are probably 50 other equivalently useful functions that should be
included in R*RS. I believe that this is a slipery slope onto which we don't
want to tread. If there is some reason that people think that these two
functions are particularly useful or are not easily implemented in the core
language, I would be very interested in hearing those arguments. Noone seemed
to be able to generate them at Snowbird.
Morry Katz
katz@polya.stanford.edu
∂19-Jun-89 1906 @mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu another change for R4RS; peek-char
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 19 Jun 89 19:05:56 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa25509;
19 Jun 89 17:31 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 19 Jun 89 16:59:37 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa20986;
19 Jun 89 16:36 EDT
Received: from ZURICH.AI.MIT.EDU ([18.43.0.172]) by life.ai.mit.edu (4.0/AI-4.10) id AA02216; Mon, 19 Jun 89 16:36:40 EDT
Return-Path: <cph@ZURICH.AI.MIT.EDU>
Received: by ZURICH.AI.MIT.EDU; Mon, 19 Jun 89 16:33:22 edt
Date: Mon, 19 Jun 89 16:33:22 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
Message-Id: <8906192033.AA22514@ZURICH.AI.MIT.EDU>
To: mkatz@sesame.stanford.edu
Cc: will@fog.cs.uoregon.edu, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Morris Katz's message of Mon, 19 Jun 89 09:55:15 PDT <8906191655.AA09188@sesame.Stanford.EDU>
Subject: another change for R4RS; peek-char
Date: Mon, 19 Jun 89 09:55:15 PDT
From: mkatz@sesame.stanford.edu (Morris Katz)
Date: Fri, 2 Jun 89 15:15:37 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
Reply-To: cph@zurich.ai.mit.edu
Date: Tue, 30 May 89 17:08:52 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
One person has objected, strongly, to making list-ref and list-tail
essential. Does anyone wish to counter by explaining just why it
is essential that these procedures be essential?
The reason is the following (extracted from the Working Group on
Scheme's unapproved minutes of the Feb. 3 meeting):
6.1 Procedures to be deleted from the standard.
Moved, seconded, and approved: keep LIST-REF, LIST-TAIL, and
SUBSTRING, and delete STRING->LIST, LIST->STRING, STRING-COPY,
STRING-FILL!, VECTOR->LIST, LIST->VECTOR, and VECTOR-FILL!. Since
LIST-REF and LIST-TAIL are non-essential features in R4RS, we need the
author's agreement to change them to essential.
This is required because the Working Group does not wish to
standardize on anything that is inessential in R*RS. If R*RS decides
to keep these procedures inessential, the WG will be forced to drop
them from the standard.
I suppose this can be thought of as a strong recommendation from the
WG to R*RS that it is desirable to keep these procedures.
In the original discussions on standardization, a concern was expressed that
the standards effort would try to foist changes on the R*RS community. We were
assured that this was not the case and any changes to R*RS would be made on
their own merits. I hope this position has not changed already!!! It is the
Working Groups decision to create a standard which only includes essential
features from R*RS. This decision should have not standing in R*RS
discussions.
Morry Katz
katz@polya.stanford.edu
No one is trying to "foist changes" on the R*RS community. The
standards Working Group has made a REQUEST that this be changed. If
the authors refuse the request, as is their prerogative, the Working
Group will accept that decision.
Please don't read more political intent into my message than was there
already, even if it does help to reinforce your position. I thought I
was quite clear as to the nature of the request, including the
possibility that the working group might have to deal with a refusal.
∂19-Jun-89 1907 @mc.lcs.mit.edu:mkatz@sesame.stanford.edu another change for R4RS; peek-char
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 19 Jun 89 19:07:35 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa17117;
19 Jun 89 19:27 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 19 Jun 89 19:25:51 EDT
Received: from Sesame.Stanford.EDU by mintaka.lcs.mit.edu id aa11775;
19 Jun 89 19:24 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA10258; Mon, 19 Jun 89 14:52:57 PDT
Date: Mon, 19 Jun 89 14:52:57 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8906192152.AA10258@sesame.Stanford.EDU>
To: cph@zurich.ai.mit.edu
Cc: will@fog.cs.uoregon.edu, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Chris Hanson's message of Mon, 19 Jun 89 16:33:22 edt <8906192033.AA22514@ZURICH.AI.MIT.EDU>
Subject: another change for R4RS; peek-char
Date: Mon, 19 Jun 89 16:33:22 edt
From: cph@ZURICH.AI.MIT.EDU (Chris Hanson)
Date: Mon, 19 Jun 89 09:55:15 PDT
From: mkatz@sesame.stanford.edu (Morris Katz)
Date: Fri, 2 Jun 89 15:15:37 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
Reply-To: cph@zurich.ai.mit.edu
Date: Tue, 30 May 89 17:08:52 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
One person has objected, strongly, to making list-ref and list-tail
essential. Does anyone wish to counter by explaining just why it
is essential that these procedures be essential?
The reason is the following (extracted from the Working Group on
Scheme's unapproved minutes of the Feb. 3 meeting):
6.1 Procedures to be deleted from the standard.
Moved, seconded, and approved: keep LIST-REF, LIST-TAIL, and
SUBSTRING, and delete STRING->LIST, LIST->STRING, STRING-COPY,
STRING-FILL!, VECTOR->LIST, LIST->VECTOR, and VECTOR-FILL!. Since
LIST-REF and LIST-TAIL are non-essential features in R4RS, we need the
author's agreement to change them to essential.
This is required because the Working Group does not wish to
standardize on anything that is inessential in R*RS. If R*RS decides
to keep these procedures inessential, the WG will be forced to drop
them from the standard.
I suppose this can be thought of as a strong recommendation from the
WG to R*RS that it is desirable to keep these procedures.
In the original discussions on standardization, a concern was expressed that
the standards effort would try to foist changes on the R*RS community. We were
assured that this was not the case and any changes to R*RS would be made on
their own merits. I hope this position has not changed already!!! It is the
Working Groups decision to create a standard which only includes essential
features from R*RS. This decision should have not standing in R*RS
discussions.
Morry Katz
katz@polya.stanford.edu
No one is trying to "foist changes" on the R*RS community. The
standards Working Group has made a REQUEST that this be changed. If
the authors refuse the request, as is their prerogative, the Working
Group will accept that decision.
Please don't read more political intent into my message than was there
already, even if it does help to reinforce your position. I thought I
was quite clear as to the nature of the request, including the
possibility that the working group might have to deal with a refusal.
Maybe I reacted too strongly to this request, and I apologize to all if I did.
However, it is my opinion that a change is being advocated to R*RS based on no
technical arguments, but only political ones. At Snowbird, there were those of
us who advocated removing the functions in question from R*RS altogether and
others who wanted to make them essential. We reached a compromise that these
functions would remain inessential. I am afraid that if the question is
phrased in such a way that essential status and elimination become the only
viable alternatives, I will be forced to also break the truce and crusade for
elimination.
Morry Katz
katz@polya.stanford.edu
∂19-Jun-89 2242 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #141
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 19 Jun 89 22:42:11 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa25176;
20 Jun 89 1:12 EDT
Date: 20 JUN 89 00:07:16 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #141
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID: <8906200112.aa25176@mintaka.lcs.mit.edu>
Scheme Digest #141 20 JUN 89 00:07:16 EDT
Today's Topics:
"unspecified" and SET!
"unspecified" and SET!
----------------------------------------------------------------------
Date: Mon, 19 Jun 89 15:26 EDT
From: Alan Bawden <Alan@REAGAN.AI.MIT.EDU>
Subject: "unspecified" and SET!
Message-ID: <19890619192610.2.ALAN@PIGPEN.AI.MIT.EDU>
Date: 18 Jun 89 23:17:50 GMT
From: Dorai Sitaram <titan!dorai@rice.edu>
...
Perhaps, SET! is not the ideal side-effecting construct for an
expression-oriented language. Felleisen and Friedman [1] propose a
side-effecting construct called a SIGMA-capability. This looks just
like a LAMBDA-expression, but whereas LAMBDA introduces new bound
variables, SIGMA modifies the binding of existing lexical variables.
In other words, on applying a SIGMA-capability to arguments, the
variables corresponding to the SIGMA-parameters are side-effected.
Problems about "unspecified" return values disappear....
I'm having a hard time applying this idea to the NEWLINE procedure -- which
is specified in R3RS to return an unspecified value. Is the idea to
introduce a side-effecting construct that looks like LAMBDA, but performs a
newline when applied to an output port?
((NULINE () <body>)
(CURRENT-OUTPUT-PORT))
------------------------------
Date: 19 Jun 89 23:24:37 GMT
From: Dorai Sitaram <titan!dorai@rice.edu>
Subject: Re: "unspecified" and SET!
Message-Id: <3904@kalliope.rice.edu>
In response to my posting suggesting SIGMA and SIGMA-based SET! (a la
LAMBDA and LET) instead of traditional SET!, I received email which
basically states that SIGMA violates the orthogonality of Scheme
constructs, viz., SIGMA does "two" things: it "side-effects the
environment" _and_ "returns a value".
In other words, it is felt that any side-effecting construct should
just perform the job it was made for, viz., side-effecting, and not do
something else too, like returning values. SIGMA allegedly "fails" in
the latter detail.
But then, we should remember that our goal was to preserve the
syntactic uniformity of Scheme. Scheme is (and very deliberately too)
an expression-oriented language. In spite of our best efforts,
traditional SET! does return a value. Given that whichever primitive
side-effecting construct we pick will inevitably return a value, which
construct should we choose? I would prefer one where the returned
value is not only meaningful but _necessary_.
The value that SET! returns is totally arbitrary. What SIGMA returns
is crucial to its correctness. Recall that SIGMA does not perform a
side-effect immediately; it returns a closure, which needs to be
applied to value(s) before any side-effecting can take place.
(Incidentally, LAMBDA, the cornerstone of Scheme, also has "two"
purposes _if_ we take "returning a value" as a distinguishing property
in assessing the orthogonality of Scheme. LAMBDA introduces fresh
lexical variables _and_ returns a closure. I don't think anyone
seriously wants to reject LAMBDA for lack of orthogonality!)
--dorai
ps: Other questions:
* Why was SIGMA created? Felleisen & Friedman (POPL 1987) devised a
calculus for a lambda-calculus-like language with assignments. SIGMA
kind of falls out naturally.
* Why is it "superior" to SET!? "Superior" is a tough word. However, I
did mention the naturalness of parallel assignment in my orig.
posting. Using SIGMA-capabilities as arguments to control-reifiers
like call/cc is also delicious.
* There is also another reason why the SIGMA-model of assignment, viz.,
(sigma (x ...) e ...) or (set! ([x a] ...) e ...), makes sense. In any
program, one always performs some operation _after_ the
side-effecting (of variable-bindings(see + below)) has been done. If
the side-effecting were the last thing done in the program, there is
no way it could be detected, hence no way it could be meaningful.
Thus the application of a SIGMA-capability returns the value of the
body of the SIGMA-expression, something (and such a something
invariably exists) that is evaluated _after_ the side-effecting has
taken place.
+{PRINTF is the only side-effect which can meaningfully be the last
thing in a program.}
* [Alan Bawden's question about NEWLINE...]
How do you deal with the other "commands" of Scheme? (E.g., READ,
SET-CAR!, PRINTF.) Easier than SET!. SIGMA-like counterparts need
_not_ be made for these, as that would lead to a plethora of special
forms (as opposed to 'procedures'). All of these "command"
procedures now take an additional argument for "the body" (thunk
actually) whose value is returned.
{* SIGMA of course is necessarily a special form (i.e., it cannot be
substituted by a procedure as for READ, SET-CAR!, PRINTF above).
The reason is variable names can't be passed as procedure arguments.}
--dorai
-------------------------------------------------------------------------------
It may be that the gulfs will wash us down;
It may be we shall touch the Happy Isles.
-------------------------------------------------------------------------------
------------------------------
End of Scheme Digest
********************
∂20-Jun-89 0721 @mc.lcs.mit.edu:shaff@sesame.stanford.edu Useful, but not essential
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 20 Jun 89 07:21:30 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id ab06077;
20 Jun 89 10:17 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 20 Jun 89 10:14:15 EDT
Received: from Sesame.Stanford.EDU by mintaka.lcs.mit.edu id aa19354;
20 Jun 89 10:10 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA13286; Tue, 20 Jun 89 07:09:44 PDT
Date: Tue, 20 Jun 89 07:09:44 PDT
From: Mike Shaff <shaff@sesame.stanford.edu>
Message-Id: <8906201409.AA13286@sesame.Stanford.EDU>
To: rrrs-authors@mc.lcs.mit.edu
Subject: Useful, but not essential
ciao,
I hesitate to enter into this seemingly charged arena, but...
It is my opinion that non-essential procedures, were to be considered
potentially useful for the user, hence implementors were given a possible
binding for the specified functionality. This was a method by which we could
avoid having standard 'user environment' procedures with wildly divergent
names/functionality.
I must admit my bias away from the inclusion of easily built procedures (and
macros, someday... ahhh someday ;>). If one looks at the Brooks and Gabriel
paper entitled 'A Critique of Common Lisp' (reference below) the first
desirable property is written of as:
Intellectual Conciseness. A language should be small enough for a programmer
to be able to keep all of it in mind when programming.
I recognize that the introduction of essential procedures does not introduce
primitives (the focus of Brooks and Gabriel's paragraph), however I do think
that the principle can be applied here. (NOTE: I was one of the people that
advocated the complete removal of a number of non-essential constructs).
I share Chris Hansons's hope that this (and all future) discussions return to
a tone of tech/fun.
(peace chance)
mas
∂20-Jun-89 0754 @mc.lcs.mit.edu:shaff@sesame.stanford.edu Useful, but not essential: the reference
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 20 Jun 89 07:54:35 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa14878;
20 Jun 89 10:35 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 20 Jun 89 10:19:48 EDT
Received: from Sesame.Stanford.EDU by mintaka.lcs.mit.edu id aa04769;
20 Jun 89 10:16 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA13322; Tue, 20 Jun 89 07:16:22 PDT
Date: Tue, 20 Jun 89 07:16:22 PDT
From: shaff@sesame.stanford.edu (Mike Shaff)
Message-Id: <8906201416.AA13322@sesame.Stanford.EDU>
To: rrrs-authors@mc.lcs.mit.edu
Subject: Useful, but not essential: the reference
ciao,
Not being of sound mind I forgot the promised reference.
Brooks, R. A. & Gabriel R. P., A Critique of Common Lisp, Proceedings of 1984
Symposium on LISP and Functional Programming, ACM, New York, 1984.
(peace chance)
mas
∂20-Jun-89 1323 @mc.lcs.mit.edu,@zermatt.lcs.mit.edu:ziggy@hx.lcs.mit.edu RE: Sticks and stones
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 20 Jun 89 13:23:48 PDT
Received: by mintaka.lcs.mit.edu id af03592; 20 Jun 89 16:08 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa03474;
20 Jun 89 16:01 EDT
Received: from ZERMATT.LCS.MIT.EDU (CHAOS 17316) by MC.LCS.MIT.EDU 20 Jun 89 15:59:32 EDT
Received: from HX.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via INTERNET with SMTP id 267427; 20 Jun 89 15:58:29 EDT
Received: by hx.LCS.MIT.EDU (5.51/4.7); Tue, 20 Jun 89 15:58:40 EDT
Date: Tue, 20 Jun 89 15:58:40 EDT
From: "Michael R. Blair" <ziggy@hx.lcs.mit.edu>
Message-Id: <8906201958.AA15522@hx.LCS.MIT.EDU>
To: rrrs-authors@zermatt.lcs.mit.edu
Subject: RE: Sticks and stones
I vaguely recall an agreement a short time ago that there was going to
be a Standard Library of Scheme procedures. It was my understanding at the
time that all inessential procedures were going to be migrated to this
section (this may have been a halucination on my part).
Perhaps we could rechannel our hostilities between the Standards folks
and the R* folks into fulfilling that unforced promise to all submit
useful nonessential stuff to the Librarian.
This should also stimulate a discussion among the standards folks on
whether the R* Standardized Library stuff should be in the Standard
or not. That, I think, should be the sole issue to be discussed...
blackmailing the R* folks should not be the issue (you know, ``if
you folks don;t make this essential in *your* report then you can't
have it in *our* standard''. That is the ultimatum as I see it.)
Is focussing on the Library a viable alternative to sticks and stones
or am I just tossing another stick/stone?
This is not a flame. ~Ziggy
∂20-Jun-89 1424 @mc.lcs.mit.edu,@ZERMATT.lcs.mit.edu:jinx@zurich.ai.mit.edu Sticks and stones
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 20 Jun 89 14:24:17 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa14327;
20 Jun 89 17:04 EDT
Received: from ZERMATT.LCS.MIT.EDU (CHAOS 17316) by MC.LCS.MIT.EDU 20 Jun 89 17:02:14 EDT
Received: from ZURICH.AI.MIT.EDU (CHAMARTIN.AI.MIT.EDU) by ZERMATT.LCS.MIT.EDU via INTERNET with SMTP id 267471; 20 Jun 89 17:01:11 EDT
Return-Path: <jinx@ZURICH.AI.MIT.EDU>
Received: by ZURICH.AI.MIT.EDU; Tue, 20 Jun 89 16:58:22 edt
Date: Tue, 20 Jun 89 16:58:22 edt
From: "Guillermo J. Rozas" <jinx@zurich.ai.mit.edu>
Message-Id: <8906202058.AA02376@ZURICH.AI.MIT.EDU>
To: ziggy@hx.lcs.mit.edu
Cc: rrrs-authors@ZERMATT.lcs.mit.edu
In-Reply-To: "Michael R. Blair"'s message of Tue, 20 Jun 89 15:58:40 EDT <8906201958.AA15522@hx.LCS.MIT.EDU>
Subject: Sticks and stones
Reply-To: jinx@zurich.ai.mit.edu
I'm confused about the perceived ultimatum and hostilities between the
IEEE and RnRS communities.
To start with, please remember that the intersection between the IEEE
working group and the RnRS community is almost exactly the IEEE WG.
Thus this is internal fighting inside the RnRS community.
Second, some of you have perceived the request to reexamine the
decision to make the LIST-MUMBLEs essential as an ultimatum. It is
nothing of the sort, nor does it want to be.
The IEEE WG decided that the procedures were usefuly enough that they
deserved to be in the standard. Note that the decision of exactly
what set of procedures to standardize over is purely a matter of
aesthetics and practicality, never a technical reason. While everyone
(as far as I know) agrees that we should standardize on LENGTH, it is
obvious that other procedures are much more controversial.
The WG has very strong feelings about making the IEEE draft standard a
strict subset of the essential subset of the appropriate RnRS. It
therefore politely requested reexamination of the decision to make the
LIST-MUMBLEs essential. The answer came back saying NO. There was no
intended coercion or anything after that. Why all the antagonism?
Please calm down, and READ the messages being sent.
∂20-Jun-89 1428 @mc.lcs.mit.edu,@zermatt.lcs.mit.edu:mkatz@sesame.stanford.edu Sticks and stones
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 20 Jun 89 14:27:58 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa29905;
20 Jun 89 16:56 EDT
Received: from ZERMATT.LCS.MIT.EDU (CHAOS 17316) by MC.LCS.MIT.EDU 20 Jun 89 16:31:55 EDT
Received: from sesame.Stanford.EDU (INTERNET|36.22.0.169) by ZERMATT.LCS.MIT.EDU via INTERNET with SMTP id 267450; 20 Jun 89 16:30:43 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA14897; Tue, 20 Jun 89 13:29:37 PDT
Date: Tue, 20 Jun 89 13:29:37 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8906202029.AA14897@sesame.Stanford.EDU>
To: ziggy@hx.lcs.mit.edu
Cc: rrrs-authors@zermatt.lcs.mit.edu
In-Reply-To: "Michael R. Blair"'s message of Tue, 20 Jun 89 15:58:40 EDT <8906201958.AA15522@hx.LCS.MIT.EDU>
Subject: Sticks and stones
Date: Tue, 20 Jun 89 15:58:40 EDT
From: "Michael R. Blair" <ziggy@hx.lcs.mit.edu>
I vaguely recall an agreement a short time ago that there was going to
be a Standard Library of Scheme procedures. It was my understanding at the
time that all inessential procedures were going to be migrated to this
section (this may have been a halucination on my part).
Perhaps we could rechannel our hostilities between the Standards folks
and the R* folks into fulfilling that unforced promise to all submit
useful nonessential stuff to the Librarian.
This should also stimulate a discussion among the standards folks on
whether the R* Standardized Library stuff should be in the Standard
or not. That, I think, should be the sole issue to be discussed...
blackmailing the R* folks should not be the issue (you know, ``if
you folks don;t make this essential in *your* report then you can't
have it in *our* standard''. That is the ultimatum as I see it.)
Is focussing on the Library a viable alternative to sticks and stones
or am I just tossing another stick/stone?
This is not a flame. ~Ziggy
I strongly support your call for resurrecting the library (yellow pages).
Somehow the library seems to have died, I suspect as a result of the lack of a
standard macro facility. Many of the things people wanted to place in the
library cannot be written in an implementation independent fashion (i.e., in
R*RS) without standard macros. Therefore, lets get macros and the library
going ASAP.
Morry Katz
katz@polya.stanford.edu
∂20-Jun-89 1437 @MC.lcs.mit.edu,@life.ai.mit.edu:Stewart.Clamen@clamen.avalon.cs.cmu.edu LIST-REF and LIST-TAIL
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 20 Jun 89 14:37:27 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id ac01489;
20 Jun 89 17:15 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 20 Jun 89 17:08:27 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id ab12917;
20 Jun 89 17:03 EDT
Received: from ZURICH.AI.MIT.EDU by life.ai.mit.edu (4.0/AI-4.10) id AA03103; Tue, 20 Jun 89 17:03:11 EDT
Return-Path: <Stewart.Clamen@clamen.avalon.cs.cmu.edu>
Received: from CLAMEN.AVALON.CS.CMU.EDU ([128.2.220.41]) by ZURICH.AI.MIT.EDU; Tue, 20 Jun 89 17:00:22 edt
Message-Id: <8906202100.AA02883@ZURICH.AI.MIT.EDU>
Date: Tue, 20 Jun 89 17:02:10 EDT
From: Stewart.Clamen@cs.cmu.edu
To: scheme-standard@zurich.ai.mit.edu
Cc: rrrs-authors@zurich.ai.mit.edu
Subject: LIST-REF and LIST-TAIL
Reply-To: clamen@cs.cmu.edu
Does anyone who was at the last Standardization meeting remember the
motivations which led to our desire to have LIST-REF and LIST-TAIL in
the language (and thus resulting in a request of the R*RS Group to
promote the two procedures from "optional" to "essential")? I was
there, but I cannot recall the discussion that led to this decision.
Perhaps if those ideas were resurrected now for the benefit of R*RS,
we might be able to resolve this issue and get on to more important
things?
SMC
P.S. I really don't want to send this to BOTH lists, but what choice
do I have?
∂20-Jun-89 1500 @mc.lcs.mit.edu,@ZERMATT.lcs.mit.edu:cph@ZURICH.ai.mit.edu Sticks and stones
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 20 Jun 89 14:59:52 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa16724;
20 Jun 89 17:50 EDT
Received: from ZERMATT.LCS.MIT.EDU (CHAOS 17316) by MC.LCS.MIT.EDU 20 Jun 89 17:48:00 EDT
Received: from ZURICH.AI.MIT.EDU by ZERMATT.LCS.MIT.EDU via INTERNET with SMTP id 267499; 20 Jun 89 17:47:00 EDT
Return-Path: <cph@ZURICH.AI.MIT.EDU>
Received: by ZURICH.AI.MIT.EDU; Tue, 20 Jun 89 17:44:14 edt
Date: Tue, 20 Jun 89 17:44:14 edt
From: Chris Hanson <cph@ZURICH.ai.mit.edu>
Message-Id: <8906202144.AA03583@ZURICH.AI.MIT.EDU>
To: jinx@ZURICH.ai.mit.edu
Cc: rrrs-authors@ZERMATT.lcs.mit.edu
In-Reply-To: "Guillermo J. Rozas"'s message of Tue, 20 Jun 89 16:58:22 edt <8906202058.AA02376@ZURICH.AI.MIT.EDU>
Subject: Sticks and stones
Date: Tue, 20 Jun 89 16:58:22 edt
From: "Guillermo J. Rozas" <jinx@zurich.ai.mit.edu>
It
therefore politely requested reexamination of the decision to make the
LIST-MUMBLEs essential. The answer came back saying NO.
More precisely: some members of the authors committee have replied NO.
∂20-Jun-89 1542 @mc.lcs.mit.edu,@zermatt.lcs.mit.edu:mkatz@sesame.stanford.edu Sticks and stones
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 20 Jun 89 15:39:19 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa05171;
20 Jun 89 18:27 EDT
Received: from ZERMATT.LCS.MIT.EDU (CHAOS 17316) by MC.LCS.MIT.EDU 20 Jun 89 18:25:21 EDT
Received: from SESAME.STANFORD.EDU by ZERMATT.LCS.MIT.EDU via INTERNET with SMTP id 267520; 20 Jun 89 18:24:16 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA15385; Tue, 20 Jun 89 15:23:41 PDT
Date: Tue, 20 Jun 89 15:23:41 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8906202223.AA15385@sesame.Stanford.EDU>
To: rrrs-authors@zermatt.lcs.mit.edu
In-Reply-To: Chris Hanson's message of Tue, 20 Jun 89 17:44:14 edt <8906202144.AA03583@ZURICH.AI.MIT.EDU>
Subject: Sticks and stones
The general consensus seems to be that my original message on list-tail and
list-ref read much more strongly than I intended. Again, my sincerest
apologies to cph and anyone else in the WG who I offended. I only wanted to
express my feeling that standardization should not carry any more weight in
R*RS discussions than that which would normally be given to members of
the WG as members of the R*RS community. I continue to believe that list-tail
and list-ref should not become essential procedures, but not at the expense of
losing friends. There are more important battles to be fought.
Morry Katz
katz@polya.stanford.edu
∂20-Jun-89 1644 @mc.lcs.mit.edu,@life.ai.mit.edu,@fog.cs.uoregon.edu:will@cs.uoregon.edu LIST-REF, LIST-TAIL
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 20 Jun 89 16:44:11 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa07266;
20 Jun 89 19:34 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 20 Jun 89 19:32:57 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa07207;
20 Jun 89 19:27 EDT
Received: from ZURICH.AI.MIT.EDU by life.ai.mit.edu (4.0/AI-4.10) id AA05327; Tue, 20 Jun 89 19:27:03 EDT
Return-Path: <@fog.cs.uoregon.edu:will@cs.uoregon.edu>
Received: from skinner.cs.uoregon.edu ([128.223.4.13]) by ZURICH.AI.MIT.EDU; Tue, 20 Jun 89 19:24:08 edt
Received: from fog.cs.uoregon.edu by skinner.cs.uoregon.edu with SMTP
(5.59++/IDA-1.2.8) id AA14125; Tue, 20 Jun 89 16:26:27 PDT
Received: by fog.cs.uoregon.edu; Tue, 20 Jun 89 16:24:24 PDT
Date: Tue, 20 Jun 89 16:24:24 PDT
From: will@cs.uoregon.edu
Message-Id: <8906202324.AA11051@fog.cs.uoregon.edu>
To: cph@zurich.ai.mit.edu
Subject: LIST-REF, LIST-TAIL
Cc: rrrs-authors@zurich.ai.mit.edu
Chris, I think it would help the authors if you could explain why the
P1178 group feels that LIST-REF and LIST-TAIL need to be in the IEEE
standard. Right now the only thing we've got to go on is the fact that
P1178 has requested that they be made essential. As an editor of R4RS,
I don't feel comfortable making that change (in the face of a contrary
decision at Snowbird and an objection recently registered on rrrs-authors)
without some kind of technical rationale.
Peace, Will
∂20-Jun-89 2306 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #142
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 20 Jun 89 23:06:44 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa12949;
21 Jun 89 1:19 EDT
Date: 21 JUN 89 00:08:03 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #142
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID: <8906210119.aa12949@mintaka.lcs.mit.edu>
Scheme Digest #142 21 JUN 89 00:08:03 EDT
Today's Topics:
"unspecified" and SET!
"unspecified" and SET!
"unspecified" and SET!
----------------------------------------------------------------------
Date: 20 Jun 89 01:48:58 GMT
From: Vincent Manis <att!alberta!ubc-cs!grads.cs.ubc.ca!manis@bloom-beacon.mit.edu>
Subject: Re: "unspecified" and SET!
Message-Id: <2281@ubc-cs.UUCP>
I've bitten my tongue on this, but I really can't see the point of
#!unspecified. Perhaps it would be nice in theory (especially if
(define loop
(lambda (x)
(loop (1+ x))))
returned #!unspecified, which would then be equivalent to `bottom' in
the Scott-Strachey world), but it seems pointless.
One can argue, as somebody has, that the existing behaviour
distinguishes between expressions and commands; however, Scheme already
has a strong notion of side effects (unlike, say, Miranda), and
whether a side-effecting procedure yields (), #f, an unspecified
result, or #!unspecified really makes no difference to anybody, except
in one place, which I'll mention in a moment.
I regard `returns an unspecified result' as an injunction not to place
a call to a procedure in a value-returning position, e.g., the last
step in a lambda or begin. If I wrote a Scheme compiler, fascist that
I am, I would probably generate an error message for such a usage.
Going to the trouble to develop a calculus of unspecified values
strikes me as almost as silly as some of the things I did when I was
involved in writing an Algol 68 compiler.
The one place where #!unspecified makes some sense is in
Read-Eval-Print loops. One can use #!unspecified as a trigger that the
result is not to be printed. But then one does not need to change the
language: PC Scheme, for example, has *the-non-printing-object*.
If it ain't broke, don't fix it.
____________ Vincent Manis | manis@cs.ubc.ca
___ \ _____ The Invisible City of Kitezh | manis@cs.ubc.cdn
____ \ ____ Department of Computer Science | manis%cs.ubc@relay.cs.net
___ /\ ___ University of British Columbia | uunet!ubc-cs!manis
__ / \ __ Vancouver, BC, Canada V6T 1W5 | (604) 228-2394
_ / __ \ _ "Theoretical computer science helps me convince people that
____________ my indecisiveness is really Nondeterminism, which sounds like
a much more positive characteristic." -- a student
------------------------------
Date: 20 Jun 89 16:29:44 GMT
From: Brad Pierce <pierce@locus.ucla.edu>
Subject: Re: "unspecified" and SET!
Message-Id: <25058@shemp.CS.UCLA.EDU>
In article <2281@ubc-cs.UUCP> manis@grads.cs.ubc.ca (Vincent Manis) writes:
<< Stuff omitted. >>
>I regard `returns an unspecified result' as an injunction not to place
>a call to a procedure in a value-returning position, e.g., the last
>step in a lambda or begin. If I wrote a Scheme compiler, fascist that
>I am, I would probably generate an error message for such a usage.
<< Stuff omitted. >>
This is really not a criticsm, only a question. How does one go about
building a compiler that can detect when a procedure is going to
return an unspecified result, especially those which sometime return
unspecified values and sometimes return specified values? For example,
in an object-oriented program most objects will respond to some
messages with actual information and to some messages with unspecified
values. On the face of it, it sounds very difficult to determine such
things syntactically. And wouldn't runtime checking amount to
introducing the unspecified object?
It doesn't seem right to me that a user should have to know the
full specifications of an object before being able to confidently
send messages to that object. It would seem preferable to me to
be able to check whether the result returned has any information
content.
Also in this discussion I haven't heard any mention of my suggestion
to see the unspecified object as being analogous to NaN in the IEEE
numeric standard. Is that a bad analogy? Is NaN a bad idea? Just
wondering.
-- Brad
------------------------------
Date: Tue, 20 Jun 89 18:15:21 EDT
From: Alan Bawden <ALAN%ML.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU>
Subject: "unspecified" and SET!
Message-ID: <10160.890620.ALAN@ML.AI.MIT.EDU>
Date: 19 Jun 89 23:24:37 GMT
From: Dorai Sitaram <titan!dorai@rice.edu>
How do you deal with the other "commands" of Scheme? (E.g., READ,
SET-CAR!, PRINTF.) Easier than SET!. SIGMA-like counterparts need
_not_ be made for these, as that would lead to a plethora of special
forms (as opposed to 'procedures'). All of these "command"
procedures now take an additional argument for "the body" (thunk
actually) whose value is returned.
So we would write
(NEWLINE (CURRENT-OUTPUT-PORT)
(LAMBDA ()
(WRITE X (CURRENT-OUTPUT-PORT)
(LAMBDA () X))))
to newline, and then output and return the current value of X. (Or perhaps
the continuations are passed as the first argument -- it doesn't matter in
the current discussion.)
Now it would seem to me that the most uniform way to include assignment in
this scheme, is to have SET! take a continuation as well. So
(SET! X (+ X 1)
(LAMBDA () X))
would increment the value of X and return the new value.
SET! is still a keyword, so this isn't -exactly- parallel with the
side-effecting procedures. But I'll bet that once people start writing
programs using this scheme, the thing that will impress them the most is
that whenever they perform a side-effect they have to create an explicit
continuation to wait for the side-effect to happen. And I'll bet they will
be most comfortable if they have to make exactly the same kind of
continuation for SET!.
I'm currently working on a language where users really -must- control
sequencing by explicitly using thunks, so I'm very interested in linguistic
constructs that support this style. Actually, in my case its worse than in
plain Scheme, because users must also exert control over when variables are
-read- as well as written. Thus users have to write something like
(LOOK! X
(LAMBDA (VALUE)
(SET! X (+ 1 VALUE)
(LAMBDA ()
<whatever>
))))
to increment the value of X, because if they wrote
(SET! X (+ 1 X)
(LAMBDA ()
<whatever>
))
the occurrence of X in (+ 1 X) might be taken to refer to the value of X
-after- the SET! happens (so that the value of X would become the fixed
point of (lambda (n) (+ 1 n))!).
------------------------------
End of Scheme Digest
********************
∂21-Jun-89 1450 @mc.lcs.mit.edu,@life.ai.mit.edu:jinx@zurich.ai.mit.edu Librarian
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 21 Jun 89 14:50:32 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa00767;
21 Jun 89 17:27 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Jun 89 17:24:49 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa11988;
21 Jun 89 17:18 EDT
Received: from ZURICH.AI.MIT.EDU by life.ai.mit.edu (4.0/AI-4.10) id AA00513; Wed, 21 Jun 89 17:01:12 EDT
Return-Path: <jinx@ZURICH.AI.MIT.EDU>
Received: by ZURICH.AI.MIT.EDU; Wed, 21 Jun 89 13:25:19 edt
Date: Wed, 21 Jun 89 13:25:19 edt
From: "Guillermo J. Rozas" <jinx@zurich.ai.mit.edu>
Message-Id: <8906211725.AA13445@ZURICH.AI.MIT.EDU>
To: rrrs-authors%mc.lcs.mit.edu@life.ai.mit.edu
Subject: Librarian
Reply-To: jinx@zurich.ai.mit.edu
Jonathan Rees has offered to be the next Scheme librarian.
The original term was supposed to be 6 months, but it has been two years
since I was appointed, it is probably high time for someone
(especially a more activist person) to replace me.
I don't know what the proper procedure to arrane for succession is but
I guess at the very least the following steps must be taken:
1) Ask for any other interested parties. Is there anyone else?
2) Vote on a new librarian among the interested parties. This is moot
if there are no other interested parties, or they are willing to defer
to JAR.
If I don't hear from anyone else in the next two weeks, I will assume
that no one will contest Jonathan's appointment, and will send a message
announcing this fact.
∂21-Jun-89 1457 @mc.lcs.mit.edu,@life.ai.mit.edu:Gateley@tilde.csc.ti.com Re: LIST-REF and LIST-TAIL
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 21 Jun 89 14:56:14 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa05698;
21 Jun 89 17:38 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Jun 89 17:30:51 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa18618;
21 Jun 89 17:21 EDT
Received: from ZURICH.AI.MIT.EDU by life.ai.mit.edu (4.0/AI-4.10) id AA00412; Wed, 21 Jun 89 16:58:06 EDT
Return-Path: <Gateley@tilde.csc.ti.com>
Received: from ti.com (ti.com) by ZURICH.AI.MIT.EDU; Wed, 21 Jun 89 16:52:40 edt
Received: by ti.com id AA05959; Wed, 21 Jun 89 10:33:55 CDT
Received: from Casablanca by tilde id AA13214; Wed, 21 Jun 89 10:24:24 CDT
Message-Id: <2823434649-13090092@Casablanca>
Sender: GATELEY@casablanca.csc.ti.com
Date: Wed, 21 Jun 89 10:24:09 CDT
From: John Gateley <Gateley@tilde.csc.ti.com>
To: clamen@cs.cmu.edu
Cc: rrrs-authors@zurich.ai.mit.edu, scheme-standard@zurich.ai.mit.edu
Subject: Re: LIST-REF and LIST-TAIL
In-Reply-To: Msg of Tue, 20 Jun 89 17:02:10 EDT from Stewart.Clamen@cs.cmu.edu
>Does anyone who was at the last Standardization meeting remember the
>motivations which led to our desire to have LIST-REF and LIST-TAIL in
>the language (and thus resulting in a request of the R*RS Group to
>promote the two procedures from "optional" to "essential")?
As secretary for the last meeting, I have dug out my notes:
The arguments for:
There is vector-ref and string-ref, so there should be list-ref.
This conforms to Will C's law of least surprises.
These can be implemented more efficiently than the naive way if
the implementation uses cdr-coding. (And efficiency can be
considered an important issue, consider substring).
They provide continuity of error condition for reading past the end
with vector- and string-ref.
The arguments against:
They can be implemented trivially in terms of car and cdr.
They belong in an appendix (the response to this was that an
appendix is not binding).
Lists and vectors are not the same, so we shouldn't be concerned with
uniformity between them.
A final comment: At the point where it was clear that list-ref was going
to be kept, it was mentioned that list-tail should be kept too.
Hope this helps,
John
gateley@m2.csc.ti.com or gateley@csc.ti.com or gateley@zoo.csc.ti.com
∂21-Jun-89 2238 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #143
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 21 Jun 89 22:38:19 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa09436;
22 Jun 89 1:04 EDT
Date: 22 JUN 89 00:08:41 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #143
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID: <8906220104.aa09436@mintaka.lcs.mit.edu>
Scheme Digest #143 22 JUN 89 00:08:41 EDT
Today's Topics:
Scheme Digest #125
"unspecified" and SET!
"unspecified" and SET!
----------------------------------------------------------------------
Date: Wed, 21 Jun 89 15:48 EDT
From: Andre van Meulebrouck <vanMeule@allegheny.scrc.symbolics.com>
Subject: Scheme Digest #125
Message-ID: <19890621194848.5.VANMEULE@PERTA.SCRC.Symbolics.COM>
Date: Thu, 25 May 89 02:27:13 -0700
From: "Jonathan S. Shapiro" <shap@polya.stanford.edu>
Very well. I hereby specify an object whose name is
#UNSPECIFIED
Any association between this name and some meaning in your mind is
coincidental. I propose that all functions/forms that under some
conditions currently return an unspecified value should now return a
value which is EQ? to the value named by #UNSPECIFIED under those same
conditions.
Note that you are only in violation of R3RS if you *tell* me that that
is what you do...
Seriously: It's a non-damaging change, and there seems to be concensus
that it is valuable to some part of the community and has no impact to
speak of on anyone else.
Let's do it.
Jon
[Disclaimer: my opinions are purely my own.]
An off-the-cuff comment after seeing the argument posed that way (↑↑) is: "Why
not? After all there is canonical truth!".
I see a lot of parallels between canonical unspecified and canonical truth.
I'm not taking sides however, because my jury's still out and/or I don't care
enough to get really religious one way or the other about it.
BTW: I think the whole thing with nil vs. () vs. #f got a lot of mental energy
spent on it, and even after all that mind power being focused on that issue, I'm
still not convinced that things are now consistent or appreciably cleaner than
before: the net outcome seems to have hypocrisies of its own such that I'm not
convinced Scheme is truly better off than Common Lisp (on the nil issue) for all
the hubbub and hoopla.
------------------------------
Date: Wed, 21 Jun 89 14:17:54 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8906212117.AA20117@sesame.Stanford.EDU>
Subject: "unspecified" and SET!
At the R*RS meeting in Snowbird we discussed the possibility of adding some
form of multiple values to Scheme and allowing continuations to accept multiple
values. I wonder if the solution to the problem of what should be returned by
side effecting procedures like SET! is to just have them return no values (i.e.
a zero arity multiple value). As long as continuations can handle multiple
values appropriately, it seems to me that this solution would have many, if not
all, of the advantages of #!UNSPECIFIED without introducing many of the
undesirable side effects.
Morry Katz
katz@polya.stanford.edu
P.S. After the meeting at Snowbird, Guy Steele and I came to an agreement as
to the correct of the two conflicting semantics for multiple values to
continuations that we proposed. At that time, we believed that this
solution would probably be acceptable to the great majority of the
community. Is there interest in having the proposal written up for
future consideration? I would be willing to strain my memory in an
attempt to creat such a proposal if there is genuine interest.
------------------------------
Date: 21 Jun 89 22:47:44 GMT
From: Chris Haynes <chaynes@iuvax.cs.indiana.edu>
Subject: Re: "unspecified" and SET!
Message-Id: <CHAYNES.89Jun21174744@iuvax.cs.indiana.edu>
From: mkatz@SESAME.STANFORD.EDU (Morris Katz)
Newsgroups: comp.lang.scheme
Date: 21 Jun 89 21:17:54 GMT
...
P.S. After the meeting at Snowbird, Guy Steele and I came to an agreement as
to the correct of the two conflicting semantics for multiple values to
continuations that we proposed. At that time, we believed that this
solution would probably be acceptable to the great majority of the
community. Is there interest in having the proposal written up for
future consideration? I would be willing to strain my memory in an
attempt to creat such a proposal if there is genuine interest.
I'm interested.
------------------------------
End of Scheme Digest
********************
∂22-Jun-89 0706 @mc.lcs.mit.edu,@mojave.stanford.edu:shap@sid.stanford.edu Useful, but not essential
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 22 Jun 89 07:06:13 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa26763;
22 Jun 89 9:50 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 22 Jun 89 09:46:09 EDT
Received: from Mojave.Stanford.EDU by mintaka.lcs.mit.edu id aa26569;
22 Jun 89 9:38 EDT
Received: from sid.Stanford.EDU by mojave.Stanford.EDU (5.59/inc-1.0)
id AA22682; Thu, 22 Jun 89 06:36:10 PDT
Message-Id: <8906221336.AA22682@mojave.Stanford.EDU>
Received: by sid; Thu, 22 Jun 89 06:38:39 pdt
Date: Thu, 22 Jun 89 06:38:39 pdt
From: "Jonathan S. Shapiro" <shap@sid.stanford.edu>
To: shaff@sesame.stanford.edu
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Mike Shaff's message of Tue, 20 Jun 89 07:09:44 PDT <8906201409.AA13286@sesame.Stanford.EDU>
Subject: Useful, but not essential
From: Mike Shaff <shaff@sesame.stanford.edu>
It is my opinion that non-essential procedures, were to be considered
potentially useful for the user, hence implementors were given a possible
binding for the specified functionality. This was a method by which we
could avoid having standard 'user environment' procedures with wildly
divergent names/functionality.
Normally, I am inclined to agree with Mike's views. From the
perspective of someone who is interested in writing portable Scheme
programs, however, I cannot overemphasize the desirability of
standardizing certain common functionality even though it is not
strictly necessary.
*If* there existed a standard Scheme library, then I would certainly
accept the view that LIST-REF and LIST-TAIL should be part of the
library and not part of the language. In the absence of such a
library, preserving them seems warranted because of their utility.
Jon Shapiro
∂22-Jun-89 1210 @MC.lcs.mit.edu,@life.ai.mit.edu:mkatz@sesame.stanford.edu LIST-REF and LIST-TAIL
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 22 Jun 89 12:10:08 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa01255;
22 Jun 89 15:01 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 22 Jun 89 14:59:17 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa01178;
22 Jun 89 14:55 EDT
Received: from ZURICH.AI.MIT.EDU by life.ai.mit.edu (4.0/AI-4.10) id AA00684; Thu, 22 Jun 89 14:53:42 EDT
Return-Path: <mkatz@sesame.Stanford.EDU>
Received: from sesame.Stanford.EDU (sesame.stanford.edu) by ZURICH.AI.MIT.EDU; Thu, 22 Jun 89 14:50:44 edt
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA24530; Thu, 22 Jun 89 11:52:42 PDT
Date: Thu, 22 Jun 89 11:52:42 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8906221852.AA24530@sesame.Stanford.EDU>
To: Gateley@tilde.csc.ti.com
Cc: clamen@cs.cmu.edu, rrrs-authors@zurich.ai.mit.edu,
scheme-standard@zurich.ai.mit.edu
In-Reply-To: John Gateley's message of Wed, 21 Jun 89 10:24:09 CDT <2823434649-13090092@Casablanca>
Subject: LIST-REF and LIST-TAIL
Sender: GATELEY@casablanca.csc.ti.com
Date: Wed, 21 Jun 89 10:24:09 CDT
From: John Gateley <Gateley@tilde.csc.ti.com>
>Does anyone who was at the last Standardization meeting remember the
>motivations which led to our desire to have LIST-REF and LIST-TAIL in
>the language (and thus resulting in a request of the R*RS Group to
>promote the two procedures from "optional" to "essential")?
As secretary for the last meeting, I have dug out my notes:
The arguments for:
There is vector-ref and string-ref, so there should be list-ref.
This conforms to Will C's law of least surprises.
These can be implemented more efficiently than the naive way if
the implementation uses cdr-coding. (And efficiency can be
considered an important issue, consider substring).
They provide continuity of error condition for reading past the end
with vector- and string-ref.
The arguments against:
They can be implemented trivially in terms of car and cdr.
They belong in an appendix (the response to this was that an
appendix is not binding).
Lists and vectors are not the same, so we shouldn't be concerned with
uniformity between them.
A final comment: At the point where it was clear that list-ref was going
to be kept, it was mentioned that list-tail should be kept too.
Hope this helps,
John
gateley@m2.csc.ti.com or gateley@csc.ti.com or gateley@zoo.csc.ti.com
As part of an attempt to strive for uniformity, I was appointed to fill in the
gaps to make lists, vectors, and strings uniform for R4RS. I sent out a
proposal on this many moons ago and got no responses or comments. What ever
happened? Did people give up on this idea? It seems pertinent since
uniformity would require a vector-tail analogous to list-tail. Somehow
vector-tail rubs me wrong.
Morry Katz
katz@polya.stanford.edu
∂22-Jun-89 1257 @mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu [chaynes@iuvax.cs.indiana.edu: [will@cs.uoregon.edu: LIST-REF, LIST-TAIL]]
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 22 Jun 89 12:57:48 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa01860;
22 Jun 89 15:51 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 22 Jun 89 15:48:28 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa01819;
22 Jun 89 15:45 EDT
Received: from ZURICH.AI.MIT.EDU ([18.43.0.172]) by life.ai.mit.edu (4.0/AI-4.10) id AA02172; Thu, 22 Jun 89 15:44:38 EDT
Return-Path: <cph@ZURICH.AI.MIT.EDU>
Received: by ZURICH.AI.MIT.EDU; Thu, 22 Jun 89 15:41:49 edt
Date: Thu, 22 Jun 89 15:41:49 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
Message-Id: <8906221941.AA27917@ZURICH.AI.MIT.EDU>
To: rrrs-authors@mc.lcs.mit.edu
Subject: [chaynes@iuvax.cs.indiana.edu: [will@cs.uoregon.edu: LIST-REF, LIST-TAIL]]
Date: Wed, 21 Jun 89 17:38:18 -0500
From: Chris Haynes <chaynes@iuvax.cs.indiana.edu>
To: cph@ZURICH.AI.MIT.EDU
Cc: will@fog.cs.uoregon.edu
In-Reply-To: Chris Hanson's message of Tue, 20 Jun 89 19:44:57 edt <8906202344.AA04669@ZURICH.AI.MIT.EDU>
Subject: [will@cs.uoregon.edu: LIST-REF, LIST-TAIL]
Date: Tue, 20 Jun 89 19:44:57 edt
From: cph@ZURICH.AI.MIT.EDU (Chris Hanson)
Chris, can you provide this information? I don't remember precisely
what happened. All I know is that the editors recommended dropping
these procedures along with quite a few others, and at the meeting it
was voted to keep these two.
Date: Tue, 20 Jun 89 16:24:24 PDT
From: will@cs.uoregon.edu
To: cph@zurich.ai.mit.edu
Subject: LIST-REF, LIST-TAIL
Cc: rrrs-authors@zurich.ai.mit.edu
Chris, I think it would help the authors if you could explain why the
P1178 group feels that LIST-REF and LIST-TAIL need to be in the IEEE
standard. Right now the only thing we've got to go on is the fact that
P1178 has requested that they be made essential. As an editor of R4RS,
I don't feel comfortable making that change (in the face of a contrary
decision at Snowbird and an objection recently registered on rrrs-authors)
without some kind of technical rationale.
Peace, Will
You included all the info that I have, and all that I think is
relivant, in your recent note to the notesfile. There were no
technical arguments and don't need to be. The recommendation was
based on a feeling that LIST-REF and LIST-TAIL were sufficiently
important that they deserved to be standard, and they won't be as
efficient in some implementations if they aren't primitive. I expect
most people share my ambivalence on this issue. I think our
suggestion was a reasonable one, but if the rrrs-authors don't go for
it, then they win and we should move on to more important things.
∂22-Jun-89 1913 @mc.lcs.mit.edu:Pavel.pa@xerox.com Responses to a month of mail
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 22 Jun 89 19:12:59 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa12567;
22 Jun 89 22:04 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 22 Jun 89 22:02:06 EDT
Received: from Xerox.COM by mintaka.lcs.mit.edu id aa28588; 22 Jun 89 21:56 EDT
Received: from Salvador.ms by ArpaGateway.ms ; 22 JUN 89 18:56:21 PDT
Date: Thu, 22 Jun 89 18:58:58 PDT
From: Pavel.pa@xerox.com
Subject: Responses to a month of mail
In-reply-to: <8905260106.AA18779@fog.cs.uoregon.edu>
To: rrrs-authors@mc.lcs.mit.edu
Cc: Pavel.pa@xerox.com
Message-ID: <890622-185621-2108@Xerox>
Boy, I leave for a simple four-week vacation and no sooner do I get out of
the country but the various Scheme lists come to glorious life, full of
ideas and controversy. I have some comments on several things that have
been said over the past month.
=======
Date: Thu, 25 May 89 18:06:49 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Subject: planned changes to R3.95RS
Sections 2.1 (Identifiers), 2.3 (Other notations), and 7.1.1 (Lexical
structure). Add ... as a new peculiar identifier.
I would like to request that some character (preferably either period or
colon) be set aside for use in those implementations experimenting with
module facilities. In Scheme Xerox, we would like to have a notation for
``structured names'', in which the name of an ``interface'' is paired with
the name of an item in that interface. Mesa and Modula use the notation
``Foo.Bar'', CLU uses ``foo$bar'', and Common Lisp uses ``foo:bar'' and
``foo::bar''. Note that, for compatibility, the delimiter character canot
also be legal in identifiers. With the current list of special alphabetic
characters (after the acceptance of ``@'' in the list), my options are the
following:
# \ | [ ] { } , ' `
The last three of these (and the first, to a lesser extent) are not
acceptable because the possibility of an unnoticed typo is too great (when
an stray space appears before the delimiter). The brackets and braces
would look silly if they were unbalanced and are too cumbersome otherwise.
Backslash and vertical-bar look too much like escape characters (and are
such in Common Lisp).
The least unacceptable one is ``#''. I suppose that I could live with it,
but I'd sure prefer either period or colon. I'd therefore like to request
one of the following, listed in decreasing order of my preference:
1 - Remove period from the list of special subsequents (but leave ``...''
on the list of peculiar identifiers). Period is already somewhat special
because of its use in the syntax of pairs and improper lists; this and its
use in other languages for structured names, makes it the best candidate,
in my opinion.
2 - Remove colon from the list of special initials. The use of colon in
the Common Lisp (and Zetalisp) package systems is quite analagous to
structured names; there is thus significant precedence for the use of that
character in a Lisp-like language.
3 - Do nothing. Sigh.
Whichever of these is accepted, though, I'd like the report to state a
commitment to keep either the period, colon, or hash character (as
appropriate) out of identifiers in the future, specifically to allow
compatible experimentation with structured names in module systems.
=======
Date: Sun, 28 May 89 15:48:26 -0700
From: "Jonathan S. Shapiro" <shap@polya.stanford.edu>
Subject: Requested changes to R4RS
If the LOAD routine is
required to use READ, I could contemplate something like:
(define (myload file)
(let ((standard-read read))
(set! read myread)
(load file)
(set! read standard-read)))
The possibility of changing the value of a variable in the initial
environment, such as READ here, has always bothered me a great deal. In
long-lived, single address space systems, like the Lisp Machine or Cedar,
the normal mode of operation involves simultaneously running many
``programs'', usually written by different people. Changing the meaning of
one of the language primitives is very likely to have a negative impact on
the robustness of the overall system.
In addition, aside from the (also distressing) idea above, that one should
customize the behaviour of a primitive by (presumably temporarily) changing
the meaning of some other primitive, there seems to be no good reason ever
to side-effect the initial environment.
I would therefore like to request that R4RS state that it is an error to
assign to (or redefine) any of the variables defined in the report. In
particular, in Scheme Xerox, we intend to signal that error at compile-time
and would like this behaviour not to violate the specification. Please
note that this doesn't rule out the possibility of certain debugging tools
making such assignments, they just can't appear in programs.
=======
Date: Fri, 2 Jun 89 16:00:32 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Subject: Re: [ramsdell: truth of (), etc...]
<BODY> --> (define <I> <EXP>) ... <SEQUENCE> ==>
((lambda (<I> ...)
(set! <I> <EXP>)
...
<SEQUENCE>)
<UNDEFINED> ...)
(In other words, the proposal is to require that internal definitions
be
evaluated from left to right, with each succeeding definition allowed
to
use variables defined before it.)
I certainly don't want to exchange the LETREC semantics for this LET* one.
One of my most common uses for internal definitions is local recursive
procedures.
I'd like to request that the syntax and semantics of bodies and programs be
identical, but not quite like either one in R3RS. Let the syntax be
<program> ::= { <expression> | <definition> | (begin <program>) }*
<definition> ::= (define <variable> <expression>)
| (define (<variable> <def formals>) <body>)
<body> ::= <program>
so definitions and expressions can be freely mixed, both at ``top level''
and internally. Also, BEGINs at top level need not consist entirely of
definitions or entirely of expressions, as in R3.95RS. The semantics is as
follows:
-- (begin <program>) is entirely equivalent to <program> .
-- programs comprising only expressions and definitions have the same
meaning as given in the formal semantics in R3.95RS; that is, bindings are
established for all defined variables giving them unspecified values after
which the program is evaluated in sequence, treating definitions as if they
were assignments.
This is the most uniform, consistent, and useful way I can see to resolve
the difference in semantics between internal and external definitions.
Will says:
For what it's worth, here are the two reasons that I prefer the
existing
semantics:
1. I find that it is easier to understand code when I can assume
that
the order of definitions doesn't matter. That way I can read the
definitions in any order. This is a special case of the general
principle that a more declarative semantics makes programs easier
to understand.
2. (This reason is pretty weak.) For the compiler writer, I think
the
freedom to rearrange definitions makes closure analysis a little
simpler when procedure definitions are mixed with definitions of
variables containing non-procedure values.
Reason 1 would seem to apply equally well to the top level of Scheme
programs, but I suspect that Will would not be in favor of giving the
LETREC semantics to those definitions (it would make it very difficult to
get anything done). I agree with Will on the strength of the second
reason.
=======
While I'm at it, I'd like to hear from others about why we allow
(define (foo a) 17)
==> (define foo (lambda (a) 17))
but not the obvious extension of this (OK in C-Scheme, I think):
(define ((foo a) b) (+ a b))
==> (define foo
(lambda (a)
(lambda (b)
(+ a b))))
I implemented this for Cedar Scheme and have found it quite useful. I
can't see any reason to go halfway here, only allowing this abbreviation
one level deep.
=======
Just to summarize, I've made four proposals for R4RS in this message:
* Change the rules for the formation of identifiers,
* Outlaw assignments to built-in variables,
* Make the semantics of internal and external definitions identical, and
* Extend the syntax of procedure definitions.
Pavel
∂22-Jun-89 2146 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #144
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 22 Jun 89 21:46:23 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa20747;
23 Jun 89 0:40 EDT
Date: 23 JUN 89 00:10:45 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #144
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID: <8906230040.aa20747@mintaka.lcs.mit.edu>
Scheme Digest #144 23 JUN 89 00:10:45 EDT
Today's Topics:
"unspecified" and SET!
----------------------------------------------------------------------
Date: 22 Jun 89 03:27:48 GMT
From: John Gateley <apple!sun-barr!texsun!pollux!ti-csl!m2!gateley@rutgers.edu>
Subject: Re: "unspecified" and SET!
Message-Id: <81872@ti-csl.csc.ti.com>
In article <2281@ubc-cs.UUCP> manis@grads.cs.ubc.ca (Vincent Manis) writes:
>Going to the trouble to develop a calculus of unspecified values
>strikes me as almost as silly as some of the things I did when I was
>involved in writing an Algol 68 compiler.
...
>____________ Vincent Manis | manis@cs.ubc.ca
...
Do you mean Matthias Felleisen's calculus for Scheme? It is neither a
calculus of unspecified values nor silly. It is a better theoretical
basis for Scheme than the lambda value calculus: it includes both
set! style side effects and continuations in its equations.
John
gateley@m2.csc.ti.com
------------------------------
End of Scheme Digest
********************
∂23-Jun-89 0934 @mc.lcs.mit.edu:mkatz@sesame.stanford.edu Responses to a month of mail
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 23 Jun 89 09:34:11 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa13401;
23 Jun 89 12:26 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 23 Jun 89 12:22:56 EDT
Received: from Sesame.Stanford.EDU by mintaka.lcs.mit.edu id aa23571;
23 Jun 89 12:15 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA29108; Fri, 23 Jun 89 09:15:07 PDT
Date: Fri, 23 Jun 89 09:15:07 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8906231615.AA29108@sesame.Stanford.EDU>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@mc.lcs.mit.edu, Pavel.pa@xerox.com
In-Reply-To: Pavel.pa@xerox.com's message of Thu, 22 Jun 89 18:58:58 PDT <890622-185621-2108@Xerox>
Subject: Responses to a month of mail
Date: Thu, 22 Jun 89 18:58:58 PDT
From: Pavel.pa@xerox.com
Date: Sun, 28 May 89 15:48:26 -0700
From: "Jonathan S. Shapiro" <shap@polya.stanford.edu>
Subject: Requested changes to R4RS
If the LOAD routine is
required to use READ, I could contemplate something like:
(define (myload file)
(let ((standard-read read))
(set! read myread)
(load file)
(set! read standard-read)))
The possibility of changing the value of a variable in the initial
environment, such as READ here, has always bothered me a great deal. In
long-lived, single address space systems, like the Lisp Machine or Cedar,
the normal mode of operation involves simultaneously running many
``programs'', usually written by different people. Changing the meaning of
one of the language primitives is very likely to have a negative impact on
the robustness of the overall system.
In addition, aside from the (also distressing) idea above, that one should
customize the behaviour of a primitive by (presumably temporarily) changing
the meaning of some other primitive, there seems to be no good reason ever
to side-effect the initial environment.
I would therefore like to request that R4RS state that it is an error to
assign to (or redefine) any of the variables defined in the report. In
particular, in Scheme Xerox, we intend to signal that error at compile-time
and would like this behaviour not to violate the specification. Please
note that this doesn't rule out the possibility of certain debugging tools
making such assignments, they just can't appear in programs.
The operative phrase when changing a built-in definition is obviously "caveat
emptor". However, I do not believe in facist (-: languages. I would aceed to
placing a warning about rebinding primitives in R*RS, but feel quite strongly
that prohibiting such is a bad idea.
Morry Katz
katz@polya.stanford.edu
∂23-Jun-89 1328 @mc.lcs.mit.edu,@mojave.stanford.edu:shap@sid.stanford.edu Responses to a month of mail
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 23 Jun 89 13:27:59 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa02892;
23 Jun 89 16:25 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 23 Jun 89 16:21:07 EDT
Received: from Mojave.Stanford.EDU by mintaka.lcs.mit.edu id aa02724;
23 Jun 89 16:15 EDT
Received: from sid.Stanford.EDU by mojave.Stanford.EDU (5.59/inc-1.0)
id AA27573; Fri, 23 Jun 89 13:13:07 PDT
Message-Id: <8906232013.AA27573@mojave.Stanford.EDU>
Received: by sid; Fri, 23 Jun 89 13:15:34 pdt
Date: Fri, 23 Jun 89 13:15:34 pdt
From: "Jonathan S. Shapiro" <shap@sid.stanford.edu>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Pavel.pa@xerox.com's message of Thu, 22 Jun 89 18:58:58 PDT <890622-185621-2108@Xerox>
Subject: Responses to a month of mail
Regarding reserving a character for modules: I am torn. On the one
hand, it is a good idea for experimental purposes. On the other hand,
the fact that there is no general agreement on modules means that such
things won't port from one scheme to another, and I am reluctant to
see such a thing introduced into the language just when there is an
attempt to standardize - someone will subsequently decide to
standardize modules, which we don't yet have any concensus on.
Further, it strikes me that from the standpoint of the scheme system
I want
foo:bar
to be a symbol in the same way that
bar
is a symbol - the differentiation in interpretation, if any, should
happen in string-symbol (or its equivalent) in the reader.
The point is: I would buy that it would be valuable to state somewhere
in the symbol character stuff that some character [I like ':' - no
reason to be gratuitously different from existing LISP usage in the
absence of technical arguments favoring one character over another] is
intended to be used as a module separator in the future, and that
program authors are encouraged to write their programs accordingly,
but I do not think that it is necessary at this time to raise this to
the level of syntax, nor do I want to see the character removed from
the list of legal symbol name characters until their exists a compelling
rationale for doing so.
Proposal: add such a statement to R4RS.
on
∂26-Jun-89 0648 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #145
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 26 Jun 89 06:48:15 PDT
Received: by mintaka.lcs.mit.edu id ae25553; 26 Jun 89 9:20 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id ab06579;
26 Jun 89 0:39 EDT
Date: 26 JUN 89 00:07:06 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #145
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID: <8906260039.ab06579@mintaka.lcs.mit.edu>
Scheme Digest #145 26 JUN 89 00:07:06 EDT
Today's Topics:
"unspecified" and SET!
"unspecified" and SET!
----------------------------------------------------------------------
Date: 23 Jun 89 02:01:05 GMT
From: Vincent Manis <att!alberta!ubc-cs!grads.cs.ubc.ca!manis@bloom-beacon.mit.edu>
Subject: Re: "unspecified" and SET!
Message-Id: <2322@ubc-cs.UUCP>
In article <81872@ti-csl.csc.ti.com> gateley@m2.UUCP (John Gateley) writes:
>Do you mean Matthias Felleisen's calculus for Scheme? It is neither a
>calculus of unspecified values nor silly. It is a better theoretical
>basis for Scheme than the lambda value calculus: it includes both
>set! style side effects and continuations in its equations.
To clarify, let me say emphatically that I *don't* mean Felleisen's
calculus. As John says, Felleisen's work is not at all silly. I was
instead referring to the proposals for #!unspecified, which, is either
the same as `bottom' in denotational semantics or it is not. In the
former case, #!unspecified should be returned, also, in both a
division by 0 and a non-terminating recursion. In the latter case,
#!unspecified is somewhat pointless (set! could just as easily return
`()), unless one has some reason for distinguishing the two.
While I do not care for William of Ockham's metaphysics, there is much
to say for his Razor.
____________ Vincent Manis | manis@cs.ubc.ca
___ \ _____ The Invisible City of Kitezh | manis@cs.ubc.cdn
____ \ ____ Department of Computer Science | manis%cs.ubc@relay.cs.net
___ /\ ___ University of British Columbia | uunet!ubc-cs!manis
__ / \ __ Vancouver, BC, Canada V6T 1W5 | (604) 228-2394
_ / __ \ _ "Theoretical computer science helps me convince people that
____________ my indecisiveness is really Nondeterminism, which sounds like
a much more positive characteristic." -- a student
------------------------------
Date: 25 Jun 89 22:17:45 GMT
From: Dorai Sitaram <titan!dorai@rice.edu>
Subject: Re: "unspecified" and SET!
Message-Id: <4011@kalliope.rice.edu>
In article <2281@ubc-cs.UUCP> manis@grads.cs.ubc.ca (Vincent Manis) writes:
>Going to the trouble to develop a calculus of unspecified values
>strikes me as almost as silly as some of the things I did when I was
>involved in writing an Algol 68 compiler.
If this is in response to my posting(s) entitled "unspecified and
set!" (and I'm not sure it is -- Vincent doesn't say), I request
permission to shriek, "No! This is not what I meant!" ;-)
I was drawing attention to side-effecting constructs in the literature
(that they appeared in a calculus-definition is of secondary
importance) that give all the "power" of current Schemes WITHOUT
having to mess with (returning) unspecified values at all. I do, of
course, concur with Vincent that having an unspecified object like
#!unspecified is close to being the all-time great oxymoron of our
troubled times (though he might not use the selfsame words ;-]).
Second, the comparison that Vincent draws between "(#!)unspecified"
and "bottom" is not correct. "Bottom" stands for divergence
(non-termination) and occasionally, errors; "(#!)unspecified" is a
stopgap value concocted to stand for a meaningless value returned in a
TERMINATING computation.
--dorai
-------------------------------------------------------------------------------
It may be that the gulfs will wash us down;
It may be we shall touch the Happy Isles.
-------------------------------------------------------------------------------
------------------------------
End of Scheme Digest
********************
∂26-Jun-89 2154 @mc.lcs.mit.edu:Alan@REAGAN.ai.mit.edu Responses to a month of mail
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 26 Jun 89 21:54:00 PDT
Received: by mintaka.lcs.mit.edu id ag14232; 27 Jun 89 0:28 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa12978;
26 Jun 89 22:17 EDT
Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by MC.LCS.MIT.EDU 26 Jun 89 22:11:59 EDT
Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 228955; Mon 26-Jun-89 22:11:31 EDT
Date: Mon, 26 Jun 89 22:11 EDT
From: Alan Bawden <Alan@REAGAN.ai.mit.edu>
Subject: Responses to a month of mail
To: Pavel.pa@xerox.com
cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: <890622-185621-2108@Xerox>
Message-ID: <19890627021113.8.ALAN@PIGPEN.AI.MIT.EDU>
Date: Thu, 22 Jun 89 18:58:58 PDT
From: Pavel.pa@xerox.com
Date: Fri, 2 Jun 89 16:00:32 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
<BODY> --> (define <I> <EXP>) ... <SEQUENCE> ==>
((lambda (<I> ...)
(set! <I> <EXP>)
...
<SEQUENCE>)
<UNDEFINED> ...)
(In other words, the proposal is to require that internal
definitions be evaluated from left to right, with each succeeding
definition allowed to use variables defined before it.)
I certainly don't want to exchange the LETREC semantics for this LET*
one. One of my most common uses for internal definitions is local
recursive procedures.
This remark confuses me. I don't see anything LET* like about what Will
proposed here. This looks to me to be exactly what you want if you want
internal definitions to behave like top level definitions. It works just
fine to define local recursive procedures. If it was LET*-like,
definitions wouldn't be able to refer to later definitions.
∂26-Jun-89 2155 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #146
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 26 Jun 89 21:55:12 PDT
Received: by mintaka.lcs.mit.edu id ai14240; 27 Jun 89 0:29 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa13965;
27 Jun 89 0:17 EDT
Date: 27 JUN 89 00:07:05 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #146
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID: <8906270017.aa13965@mintaka.lcs.mit.edu>
Scheme Digest #146 27 JUN 89 00:07:05 EDT
Today's Topics:
Scheme Digest #145
----------------------------------------------------------------------
From: Chet Murthy <murthy@cs.cornell.edu>
Message-Id: <8906261457.AA02518@lakshmi.cs.cornell.edu>
Subject: Re: Scheme Digest #145
Date: Mon, 26 Jun 89 10:57:57 -0400
Please remove me from the Scheme mailing list.
My addresses are:
murthy@cs.cornell.edu
murthy@svax.cs.cornell.edu
Thanks,
--chet--
------------------------------
End of Scheme Digest
********************
∂27-Jun-89 1311 @mc.lcs.mit.edu:Pavel.pa@xerox.com Responses to responses to responses
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 27 Jun 89 13:11:11 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22689;
27 Jun 89 15:55 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 27 Jun 89 15:31:23 EDT
Received: from Xerox.COM by mintaka.lcs.mit.edu id aa22336; 27 Jun 89 15:27 EDT
Received: from Salvador.ms by ArpaGateway.ms ; 27 JUN 89 12:12:18 PDT
Date: Tue, 27 Jun 89 12:20:31 PDT
From: Pavel.pa@xerox.com
Subject: Responses to responses to responses
In-reply-to: <19890627021113.8.ALAN@PIGPEN.AI.MIT.EDU>
To: rrrs-authors@mc.lcs.mit.edu
Message-ID: <890627-121218-3423@Xerox>
Alan Bawden is quite right; a thinko made me misread David Bartley's
expansion of a body and think that it was a LET*-style expansion. Sigh.
=====
Morry Katz says, ``I would aceed to placing a warning about rebinding
primitives in R*RS, but feel quite strongly that prohibiting such is a bad
idea.''
This is precisely what I'm asking for. A warning would have to say
something like, ``If you redefine a primitive, you could lose horribly.''
I think we have a simple way of saying that, namely, ``It is an error to
redefine a primitive.'' The way you'll lose horribly in Scheme Xerox is
that your program won't compile. I'm not asking R4RS to prohibit
redefinition, I'm simply asking it to let me do so in my own
implementation.
I forgot to mention in my previous message the other, fairly obvious
problem with allowing redefinition. Just as a human program reader cannot
be sure of the semantics of any (even top-level) program fragment (since
the remainder of the program might redefine one or more of the primitives),
neither can the compiler. Thus, without guaranteed knowledge of the
entirety of the program, the compiler cannot both preserve the semantics of
the program and code certain primitives inline.
Contrary to Morry's semi-facetious claim that prohibiting redefinition is
``fascist'', it is the only way that a compiler can answer the twin desires
of its customers for efficiency and correctness.
=====
Jonathan Shapiro says, ``I would buy that it would be valuable to state
somewhere in the symbol character stuff that some character ... is intended
to be used as a module separator in the future, and that
program authors are encouraged to write their programs accordingly, but I
do not think that it is necessary at this time to raise this to the level
of syntax ...''
Unfortunately, I don't believe that this is sufficient. The only way
program authors can write their programs accordingly is to avoid using the
separator character at all. Otherwise, their code will not run in
implementations that use structured names, since it will very likely refer
to undefined module/interface names.
Jonathans Shapiro and Rees (the latter in private mail) recommended that
the actual sequence of characters in an identifier's name have some
semantic significance, apart from giving the identity of the identifier.
Shapiro wanted names with colons in them to behave differently than names
without colons; Rees suggested a notion somewhat like ``conc-names'' in
Common Lisp's DEFSTRUCT facility, whereby the programmer could, in a
limited scope, give special semantics to all names with a particular
prefix. These ideas feel very wrong to me, a violation of the
alpha-conversion rule. The sequence of characters in a name shouldn't have
any semantics aside from their identity.
=======
My four proposals (see my previous message) still stand; does anyone else
have any comments on them?
Pavel
∂27-Jun-89 1419 @MC.lcs.mit.edu:jinx@ZURICH.ai.mit.edu Responses to responses to responses
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 27 Jun 89 14:19:22 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa28271;
27 Jun 89 17:12 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 27 Jun 89 17:09:07 EDT
Received: from [18.43.0.171] by mintaka.lcs.mit.edu id aa08496;
27 Jun 89 17:04 EDT
Return-Path: <jinx@ZURICH.AI.MIT.EDU>
Received: by ZURICH.AI.MIT.EDU; Tue, 27 Jun 89 17:00:26 edt
Date: Tue, 27 Jun 89 17:00:26 edt
From: "Guillermo J. Rozas" <jinx@ZURICH.ai.mit.edu>
Message-Id: <8906272100.AA09821@ZURICH.AI.MIT.EDU>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@MC.lcs.mit.edu
In-Reply-To: Pavel.pa@xerox.com's message of Tue, 27 Jun 89 12:20:31 PDT <890627-121218-3423@Xerox>
Subject: Responses to responses to responses
Morry Katz says, ``I would aceed to placing a warning about rebinding
primitives in R*RS, but feel quite strongly that prohibiting such is a bad
idea.''
This is precisely what I'm asking for. A warning would have to say
something like, ``If you redefine a primitive, you could lose horribly.''
I think we have a simple way of saying that, namely, ``It is an error to
redefine a primitive.'' The way you'll lose horribly in Scheme Xerox is
that your program won't compile. I'm not asking R4RS to prohibit
redefinition, I'm simply asking it to let me do so in my own
implementation.
I think you misunderstand Morry, but just in case, I'll state my
position, which I believe coincides with his and was the consensus of
most implementors a while ago.
An implementation that does not allow assignment of the initial
variables (including those bound to procedures) in an RnRs environment
is in ERROR. Yes, I mean that. I feel very strongly that the user
takes precedence over the system.
It is acceptable, however, for an implementation to default to
"benchmark" mode, as long as the following two conditions are met:
1) There is a way to take it out of benchmark mode.
2) Appropriate warnings about redefinition/warning are given when the
implementation is in benchmark mode and an assignment/redefinition is
"attempted".
Contrary to Morry's semi-facetious claim that prohibiting redefinition is
``fascist'', it is the only way that a compiler can answer the twin desires
of its customers for efficiency and correctness.
I don't think you are right. I think a compiler can answer both,
after providing declarations. We are talking here about what
the behaviour should be in their absence. You may be right that
utmost efficiency cannot be obtained without declarations, but that is
a small price to pay.
∂27-Jun-89 2001 @MC.lcs.mit.edu,@ZERMATT.lcs.mit.edu:SCHREQ@MC.lcs.mit.edu testing
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 27 Jun 89 20:01:23 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa28060;
27 Jun 89 22:55 EDT
Received: from ZERMATT.LCS.MIT.EDU (CHAOS 17316) by MC.LCS.MIT.EDU 27 Jun 89 22:52:34 EDT
Received: from MICKEY-MOUSE.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via CHAOS with CHAOS-MAIL id 269280; Tue 27-Jun-89 22:52:30 EDT
Date: Tue, 27 Jun 89 22:52 EDT
From: Scheme Requestee <SCHREQ@MC.lcs.mit.edu>
Subject: testing
To: rrrs-authors@MC.lcs.mit.edu
Message-ID: <"19890628025210.2.schreq@MC"@MICKEY-MOUSE.LCS.MIT.EDU>
Testing the list.
∂27-Jun-89 2147 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #147
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 27 Jun 89 21:47:18 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa29209;
28 Jun 89 0:37 EDT
Date: 28 JUN 89 00:07:08 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #147
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID: <8906280037.aa29209@mintaka.lcs.mit.edu>
Scheme Digest #147 28 JUN 89 00:07:08 EDT
Today's Topics:
Looking for R*RS and XScheme source by ftp
----------------------------------------------------------------------
Date: 27 Jun 89 17:16:32 GMT
From: John Lacey <lacey@tcgould.tn.cornell.edu>
Subject: Looking for R*RS and XScheme source by ftp
Message-Id: <8271@batcomputer.tn.cornell.edu>
I'm looking for the Revised Report, as well as the
source to XScheme (by David Betz), preferably by ftp. Actually,
if anyone knows of another free Scheme implementation, I would like
to hear about it.
I'll take the report in any form I can get it, but I would
prefer a [La]TeX format.
--
John Lacey | Internet: lacey@tcgould.tn.cornell.edu
running unattached | BITnet: lacey@crnlthry
| UUCP: cornell!batcomputer!lacey
------------------------------
End of Scheme Digest
********************
∂28-Jun-89 0847 @mc.lcs.mit.edu:jinx@ZURICH.ai.mit.edu Responses to a month of mail
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 28 Jun 89 08:47:03 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa24888;
28 Jun 89 11:17 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 28 Jun 89 10:59:21 EDT
Received: from [18.43.0.171] by mintaka.lcs.mit.edu id aa24526;
28 Jun 89 10:58 EDT
Return-Path: <jinx@ZURICH.AI.MIT.EDU>
Received: by ZURICH.AI.MIT.EDU; Wed, 28 Jun 89 10:55:21 edt
Date: Wed, 28 Jun 89 10:55:21 edt
From: "Guillermo J. Rozas" <jinx@ZURICH.ai.mit.edu>
Message-Id: <8906281455.AA27360@ZURICH.AI.MIT.EDU>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Pavel.pa@xerox.com's message of Thu, 22 Jun 89 18:58:58 PDT <890622-185621-2108@Xerox>
Subject: Responses to a month of mail
Because of mailer problems on our file server (zurich), I did not read
your four point proposal until now. Here are my thoughts:
* Change the rules for the formation of identifiers,
I don't think this is warranted. I think that lexical level
conventions for module references are a bad idea.
* Outlaw assignments to built-in variables,
Definitely not. Implementations should be built in such a way that
assignment/definition in an RnRs environment does not affect the
integrity of the implementation. This should impose constraints on
the implementor, not the user. Note that single address space does
not imply a flat namespace, which Lisp Machines effectively have.
I have "ideological" reasons against this proposal, and pragmatic ones
as well.
The main ideological reason is that the system/implementation is a
tool for the user, and as such it should accomodate the wishes of the
user, not viceversa. Thus if a user wants to call CAR something he
writes/uses (in a Church pair implmentation, for example), he should
be allowed to do so.
The pragmatic reason may concern you more. Presumably you would like
implementations to be able to add new primitives to the language
described in the report. Given that the semantics of any programs
using them might be compromised in the same way that it would be when
using a "standard" primitive, you would disallow assignment and
redefinition of implementation-specific primitives as well. This
implies that portability can only be achieved by using obscure names
(ie G00034), since any "reasonable" name is potentially reserved by
some implementation.
For example: I may write my own structure facility (ignoring the
problem with portable macros, for the time being), and decide to use
my own even if the implementation provides a similar facility. I
don't want to have to change all uses of defstruct or define-structure
whenever I port to a new implementation, but your proposal might force
me to. An equivalent problem arises with the names of procedures.
* Make the semantics of internal and external definitions identical, and
I agree that they should be the same in principle. My personal
preference would be for making top level definitions behave like the
current letrec, ie. order independent. This is, unfortunately, too
radical to be accepted by most people. I prefer the current letrec
semantics to the proposed "sequential" semantics.
* Extend the syntax of procedure definitions.
MIT Scheme has had this for a while, but we've decided to back out of
it. The problem is that it does not combine well (in terms of
readability) with the following syntax for types, which we currently
believe to be a better use for parentheses in lambda lists:
(lambda ((x integer?) (y pair?))
<some code>)
∂28-Jun-89 0940 @mc.lcs.mit.edu:mkatz@sesame.stanford.edu Responses to responses to responses
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 28 Jun 89 09:40:32 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa25670;
28 Jun 89 12:13 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 28 Jun 89 11:51:01 EDT
Received: from Sesame.Stanford.EDU by mintaka.lcs.mit.edu id aa25200;
28 Jun 89 11:48 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA21003; Wed, 28 Jun 89 08:47:46 PDT
Date: Wed, 28 Jun 89 08:47:46 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8906281547.AA21003@sesame.Stanford.EDU>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Pavel.pa@xerox.com's message of Tue, 27 Jun 89 12:20:31 PDT <890627-121218-3423@Xerox>
Subject: Responses to responses to responses
Date: Tue, 27 Jun 89 12:20:31 PDT
From: Pavel.pa@xerox.com
Morry Katz says, ``I would aceed to placing a warning about rebinding
primitives in R*RS, but feel quite strongly that prohibiting such is a bad
idea.''
This is precisely what I'm asking for. A warning would have to say
something like, ``If you redefine a primitive, you could lose horribly.''
I think we have a simple way of saying that, namely, ``It is an error to
redefine a primitive.'' The way you'll lose horribly in Scheme Xerox is
that your program won't compile. I'm not asking R4RS to prohibit
redefinition, I'm simply asking it to let me do so in my own
implementation.
You have very carefully perverted what I have said to suit your own fancy. You
did not request that an implementation be allowed to prohibit redefinition of
the primitives, but stated that you wanted redefinition of a primitive to be an
error. Your original request read as follows:
"I would therefore like to request that R4RS state that it is an error to
assign to (or redefine) any of the variables defined in the report. In
particular, in Scheme Xerox, we intend to signal that error at compile-time
and would like this behavior not to violate the specification. Please note
that this doesn't rule out the possibility of certain debugging tools making
such assignments, they just can't appear in programs."
If you would like to propose something that allows your system to consider
redefinition an error but does not require my system to do such, I might be
willing to consider it.
I forgot to mention in my previous message the other, fairly obvious
problem with allowing redefinition. Just as a human program reader cannot
be sure of the semantics of any (even top-level) program fragment (since
the remainder of the program might redefine one or more of the primitives),
neither can the compiler. Thus, without guaranteed knowledge of the
entirety of the program, the compiler cannot both preserve the semantics of
the program and code certain primitives inline.
Contrary to Morry's semi-facetious claim that prohibiting redefinition is
``fascist'', it is the only way that a compiler can answer the twin desires
of its customers for efficiency and correctness.
Nearly everyones compiler currently allows a compiler directive to the effect
that primitives should be considered immutable and therefore inlineable. This
has been done for the obvious efficiency reasons and does not require that the
language specification be altered to always prohibit modifying primitives.
Morry Katz
katz@polya.stanford.edu
∂28-Jun-89 1125 @mc.lcs.mit.edu,@ZURICH.ai.mit.edu:mkatz@sesame.stanford.edu Declare proposal
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 28 Jun 89 11:25:49 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa16802;
28 Jun 89 13:08 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 28 Jun 89 12:22:43 EDT
Received: from ZURICH.AI.MIT.EDU by mintaka.lcs.mit.edu id aa25847;
28 Jun 89 12:21 EDT
Return-Path: <mkatz@sesame.Stanford.EDU>
Received: from sesame.Stanford.EDU (sesame.stanford.edu) by ZURICH.AI.MIT.EDU; Wed, 28 Jun 89 12:18:49 edt
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA21063; Wed, 28 Jun 89 09:02:14 PDT
Date: Wed, 28 Jun 89 09:02:14 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8906281602.AA21063@sesame.Stanford.EDU>
To: rrrs-authors@ZURICH.ai.mit.edu
Subject: Declare proposal
I would like to propose that we make DECLARE a special form to be used for
compiler directives. We do not have to standardize the complete format of
declare, at this time; but, I would like to set aside the name. This would
allow greater portability of programs as friendly systems could merely ignore
declarations which they don't understand and give some type of warning.
Morry Katz
katz@polya.stanford.edu
∂28-Jun-89 1345 @mc.lcs.mit.edu,@relay.cs.net,@tektronix.tek.com:kend@bloom.la.tek.com Re: A month of mail...
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 28 Jun 89 13:45:30 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa09897;
28 Jun 89 16:15 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 28 Jun 89 15:21:07 EDT
Received: from RELAY.CS.NET by mintaka.lcs.mit.edu id aa15465;
28 Jun 89 15:19 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa19941; 28 Jun 89 15:06 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
id AA00388; Wed, 28 Jun 89 12:07:15 PDT
Received: by dadla.LA.TEK.COM (5.51/6.24)
id AA26696; Wed, 28 Jun 89 12:00:57 PDT
Received: from localhost.ARPA by bloom.LA.TEK.COM (1.2/6.24)
id AA11945; Wed, 28 Jun 89 12:05:48 pdt
Message-Id: <8906281905.AA11945@bloom.LA.TEK.COM>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@mc.lcs.mit.edu
Subject: Re: A month of mail...
Date: Wed, 28 Jun 89 12:05:43 PDT
From: kend@bloom.la.tek.com
$0.02
>> * Change the rules for the formation of identifiers,
I also feel that strange naming conventions are not warrented for module
experimentation. Modules seen as compile-time early-binding, first-class
environments [(*value module-1 'foo)], etc. do not require this.
>> * Outlaw assignments to built-in variables,
[ASIDE: I prefer binding to side effects for specialization of routines.
John should be asking for more general tools:
"(define myload (make-load my-reader))"
].
You probably do want an implementation environment in which you can depend
on names to mean certain things [(define-constant car %primitive-car)], but
a user environment should be provided in which the user can rebind car
[perhaps with a warning]. As environments are outside of the language
definition, *requiring* that the user environment have immutable names
violates both the spirit and the practice of the language.
>> * Make the semantics of internal and external definitions identical, and
I like the internal semantics and would like to change the name of the
special form used in interactive loops from "define" to something else (e.g.
"defun"). The top-level-environment is an artifact of an interactive
system. We could make a naming distinction between uses/behaviors, rather
than changing uses because of a name alias.
>> * Extend the syntax of procedure definitions.
How is this going to affect other potential extensions [e.g. Dybvig & Heib's
variable-arity procedural interface]? [I don't strongly oppose this].
{After all, how much is $.02 worth?}
-Ken kend@mrloog.LA.TEK.COM
∂28-Jun-89 2147 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #148
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 28 Jun 89 21:47:25 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa17812;
29 Jun 89 0:36 EDT
Date: 29 JUN 89 00:07:25 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #148
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID: <8906290036.aa17812@mintaka.lcs.mit.edu>
Scheme Digest #148 29 JUN 89 00:07:25 EDT
Today's Topics:
Looking for R*RS and XScheme source by ftp
----------------------------------------------------------------------
Date: 28 Jun 89 10:54:44 GMT
From: Oliver Laumann <mcvax!unido!tub!net@uunet.uu.net>
Subject: Re: Looking for R*RS and XScheme source by ftp
Message-Id: <867@tub.UUCP>
In article <8271@batcomputer.tn.cornell.edu> lacey@tcgould.tn.cornell.edu (John Lacey) writes:
> if anyone knows of another free Scheme implementation, I would like
> to hear about it.
I'm going to send the sources of a Scheme interpreter to comp.sources.unix
next week. You can expect it to be posted by Rich Salz in about 4 weeks.
The interpreter is R↑3RS compatible, includes interfaces to the Xlib,
to Xt, and to the Athena and HP widget libraries of X11R3. It was
written to be used as an general extension language interpreter (to be
linked into an application); it is also useful as a stand-alone
implementation of Scheme.
Regards,
--
Oliver Laumann net@TUB.BITNET net@tub.UUCP
------------------------------
End of Scheme Digest
********************
∂28-Jun-89 2257 @mc.lcs.mit.edu:shap@sid.stanford.edu A month of mail...
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 28 Jun 89 22:57:08 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa28724;
29 Jun 89 1:26 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 29 Jun 89 01:05:06 EDT
Received: from [36.22.0.120] by mintaka.lcs.mit.edu id aa16361;
29 Jun 89 1:03 EDT
Received: from sid.Stanford.EDU by mojave.Stanford.EDU (5.59/inc-1.0)
id AA06777; Wed, 28 Jun 89 22:00:25 PDT
Message-Id: <8906290500.AA06777@mojave.Stanford.EDU>
Received: by sid; Wed, 28 Jun 89 22:03:02 pdt
Date: Wed, 28 Jun 89 22:03:02 pdt
From: "Jonathan S. Shapiro" <shap@sid.stanford.edu>
To: kend@bloom.la.tek.com
Cc: Pavel.pa@xerox.com, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: kend@bloom.la.tek.com's message of Wed, 28 Jun 89 12:05:43 PDT <8906281905.AA11945@bloom.LA.TEK.COM>
Subject: A month of mail...
Ken's comment sort of blew past a point I think is interesting. We
might be able to satisfy both desires - mutability and immutability -
by reserving some suitably small part of the namespace for system
primitives, e.g. identifiers with names whose leading substring is
"%primitive-"
Jon
∂29-Jun-89 0533 @mc.lcs.mit.edu,@mbunix.mitre.org:ramsdell@linus.mitre.org Make the semantics of internal and external definitions identical
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 29 Jun 89 05:33:47 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa20691;
29 Jun 89 8:28 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 29 Jun 89 08:24:54 EDT
Received: from mbunix.mitre.org by mintaka.lcs.mit.edu id aa20553;
29 Jun 89 8:19 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA01030; Thu, 29 Jun 89 08:16:41 EDT
Posted-Date: Thu, 29 Jun 89 08:16:35 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA01374; Thu, 29 Jun 89 08:16:35 EDT
Date: Thu, 29 Jun 89 08:16:35 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8906291216.AA01374@huxley.mitre.org>
To: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Pavel.pa@xerox.com's message of Thu, 22 Jun 89 18:58:58 PDT <890622-185621-2108@Xerox>
Subject: Make the semantics of internal and external definitions identical
Reply-To: ramsdell@mitre.org
From: Pavel.pa@xerox.com
I'd like to request that the syntax and semantics of bodies and programs be
identical, but not quite like either one in R3RS. ....
I just would like to note this is a more radical proposal than my
original proposal, and I curtainly support it.
This is the most uniform, consistent, and useful way I can see to resolve
the difference in semantics between internal and external definitions.
This is a better technical proposal than mine. However, if people
reject this idea, I hope they will still consider just changing the
semantics of internal definitions.
John
∂29-Jun-89 0956 @MC.lcs.mit.edu:Alan@REAGAN.ai.mit.edu Responses to a month of mail
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 29 Jun 89 09:56:23 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa18138;
29 Jun 89 12:51 EDT
Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by MC.LCS.MIT.EDU 29 Jun 89 12:48:29 EDT
Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 230218; Thu 29-Jun-89 12:47:54 EDT
Date: Thu, 29 Jun 89 12:47 EDT
From: Alan Bawden <Alan@REAGAN.ai.mit.edu>
Subject: Responses to a month of mail
To: jinx@ZURICH.ai.mit.edu, kend@bloom.la.tek.com
cc: Pavel.pa@xerox.com, rrrs-authors@MC.lcs.mit.edu
In-Reply-To: <8906281455.AA27360@ZURICH.AI.MIT.EDU>,
<8906281905.AA11945@bloom.LA.TEK.COM>
Message-ID: <19890629164733.2.ALAN@PIGPEN.AI.MIT.EDU>
Date: Wed, 28 Jun 89 10:55:21 edt
From: "Guillermo J. Rozas" <jinx@ZURICH.ai.mit.edu>
* Change the rules for the formation of identifiers,
I don't think this is warranted. I think that lexical level
conventions for module references are a bad idea.
Date: Wed, 28 Jun 89 12:05:43 PDT
From: kend@bloom.la.tek.com
>> * Change the rules for the formation of identifiers,
I also feel that strange naming conventions are not warrented for module
experimentation. Modules seen as compile-time early-binding, first-class
environments [(*value module-1 'foo)], etc. do not require this.
I also think that using a special lexical syntax for module references is
probably a bad idea. But I don't agree that we should prevent others from
experimentation.
The proposal, as I recall it (I don't have Pavel's original message
anymore), is -not- to declare that ":" is used for module references. The
proposal is simply to remove ":" from the list of characters you can use in
a portable program. This leaves implementations free to do whatever they
want with ":". Some will experiment with using it for module references.
Others will treat it as an ordinary symbol constituent. Some may signal
an error. (Some may even use it to introduce a new kind of comment!)
No programmer would be forced to do anything except refrain from using ":"
in portable code. You already can't use "[" portably, because there is
disagreement about what it means. I could cause a lot of trouble by
insisting that we move "[" into the list of extended alphabetic characters,
but out of deference to people who have other opinions I am willing to
simply refrain from using "[". This seems to me to be an acceptable
compromise -- I am not greatly inconvenienced by it and others are made
much happier.
Of course I am aware that others may judge the tradeoff differently.
Indeed, if we always give in to people want to reserve characters for
special purposes, we will eventually have nothing left to name our symbols
with, so the line does have to be drawn somewhere. But this colon issue
keeps coming up over and over -- it seems that we will never be free of the
pressure to demote ":" to reserved status -- so in this case I think we
should yield to that pressure.
∂29-Jun-89 1254 @mc.lcs.mit.edu,@relay.cs.net,@tektronix.tek.com:kend@bloom.la.tek.com Re: A month of mail...
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 29 Jun 89 12:54:48 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa28183;
29 Jun 89 15:44 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 29 Jun 89 15:38:36 EDT
Received: from RELAY.CS.NET by mintaka.lcs.mit.edu id aa08078;
29 Jun 89 13:25 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa22273; 29 Jun 89 13:24 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
id AA16418; Thu, 29 Jun 89 09:37:29 PDT
Received: by dadla.LA.TEK.COM (5.51/6.24)
id AA19249; Thu, 29 Jun 89 09:31:13 PDT
Received: from localhost.ARPA by bloom.LA.TEK.COM (1.2/6.24)
id AA12503; Thu, 29 Jun 89 09:36:02 pdt
Message-Id: <8906291636.AA12503@bloom.LA.TEK.COM>
To: "Jonathan S. Shapiro" <shap@sid.stanford.edu>
Cc: Pavel.pa@xerox.com, rrrs-authors@mc.lcs.mit.edu
Subject: Re: A month of mail...
In-Reply-To: Your message of Wed, 28 Jun 89 22:03:02 -0700.
<8906290500.AA06777@mojave.Stanford.EDU>
Date: Thu, 29 Jun 89 09:35:58 PDT
From: kend@bloom.la.tek.com
> Ken's comment sort of blew past a point I think is interesting. We
> might be able to satisfy both desires - mutability and immutability -
> by reserving some suitably small part of the namespace for system
> primitives, e.g. identifiers with names whose leading substring is
> "%primitive-"
>
> Jon
Sorry to belabor the point, but...
If you use a *different* namespace for the implementation environment than
for the user environment, you do *not* have to make immutable any names in
the user environment. If a user has a function to allow him access to the
implementation environment, he can be sure he is getting at a particular
primitive [barring syntactic transformations--see discussion in the
Syntactic Closures paper in the last L&FP Conf.]. By giving out an access
function without giving a mutation function, the implementation environment
is immutable *from the user's viewpoint* without doing anything special
[although you may want to do so for other reasons].
...All this without reserving any part of the user visable namespace.
-Ken kend@mrloog.LA.TEK.COM
∂29-Jun-89 1434 @mc.lcs.mit.edu,@relay.cs.net,@tektronix.tek.com:kend@bloom.la.tek.com Re: Responses to a month of mail
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 29 Jun 89 14:34:23 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22909;
29 Jun 89 17:30 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 29 Jun 89 17:27:00 EDT
Received: from RELAY.CS.NET by mintaka.lcs.mit.edu id aa22797;
29 Jun 89 17:24 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa28749; 29 Jun 89 17:20 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
id AA27434; Thu, 29 Jun 89 14:22:23 PDT
Received: by dadla.LA.TEK.COM (5.51/6.24)
id AA26610; Thu, 29 Jun 89 14:16:07 PDT
Received: from localhost.ARPA by bloom.LA.TEK.COM (1.2/6.24)
id AA12833; Thu, 29 Jun 89 14:20:56 pdt
Message-Id: <8906292120.AA12833@bloom.LA.TEK.COM>
To: Alan Bawden <Alan@REAGAN.ai.mit.edu>
Cc: jinx@ZURICH.ai.mit.edu, kend@bloom.la.tek.com, Pavel.pa@xerox.com,
rrrs-authors@mc.lcs.mit.edu
Subject: Re: Responses to a month of mail
In-Reply-To: Your message of Thu, 29 Jun 89 12:47:00 -0400.
<19890629164733.2.ALAN@PIGPEN.AI.MIT.EDU>
Date: Thu, 29 Jun 89 14:20:52 PDT
From: kend@bloom.la.tek.com
>> From: Alan Bawden <Alan@reagan.ai.mit.edu>
> ... so the line does have to be drawn somewhere. But this colon issue
> keeps coming up over and over -- it seems that we will never be free of the
> pressure to demote ":" to reserved status -- so in this case I think we
> should yield to that pressure.
I think that it is a bad idea to change the Scheme language when using an
alternate reader or syntax system which gives standard Scheme is a
fairly easy thing to do. I see no restriction in experimentation.
The *problem* I see with making #\: reserved is in portability of the above
systems. I may not have access to the implementation of Scheme which I am
using. If I want to experiment with random-module-package and the
implementation of Scheme I am using treats #\: as a comment character, I
have to bash or rewrite the reader just to get the sources I want to try out
to lex properly. If I can read symbols containing #\:, then I can
post-process the list structure which I can read using a standard reader.
I am in a much better position for experimentation if I can portably share
experiments without having to bash the implementation. Making #\: reserved
works against this.
-Ken kend@mrloog.AL.TEK.COM
(mod1:foo 3 x mod2:bar) --> ((*value mod1 'foo) 3 x (*value mod2 bar))
∂29-Jun-89 2112 @mc.lcs.mit.edu,@mojave.stanford.edu:shap@sid.stanford.edu A month of mail...
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 29 Jun 89 21:11:51 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa26611;
29 Jun 89 23:57 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 29 Jun 89 23:35:04 EDT
Received: from Mojave.Stanford.EDU by mintaka.lcs.mit.edu id aa26242;
29 Jun 89 23:34 EDT
Received: from sid.Stanford.EDU by mojave.Stanford.EDU (5.59/inc-1.0)
id AA08964; Thu, 29 Jun 89 20:31:01 PDT
Message-Id: <8906300331.AA08964@mojave.Stanford.EDU>
Received: by sid; Thu, 29 Jun 89 20:33:39 pdt
Date: Thu, 29 Jun 89 20:33:39 pdt
From: "Jonathan S. Shapiro" <shap@sid.stanford.edu>
To: kend@bloom.la.tek.com
Cc: rrrs-authors@mc.lcs.mit.edu
Subject: A month of mail...
Date: Thu, 29 Jun 89 09:35:58 PDT
From: kend@bloom.la.tek.com
> Ken's comment sort of blew past a point I think is interesting. We
> might be able to satisfy both desires - mutability and immutability -
> by reserving some suitably small part of the namespace for system
> primitives, e.g. identifiers with names whose leading substring is
> "%primitive-"
>
> Jon
Sorry to belabor the point, but...
If you use a *different* namespace for the implementation environment than
for the user environment, you do *not* have to make immutable any names in
the user environment. If a user has a function to allow him access to the
implementation environment, he can be sure he is getting at a particular
primitive [barring syntactic transformations--see discussion in the
Syntactic Closures paper in the last L&FP Conf.]. By giving out an access
function without giving a mutation function, the implementation environment
is immutable *from the user's viewpoint* without doing anything special
[although you may want to do so for other reasons].
...All this without reserving any part of the user visable namespace.
-Ken kend@mrloog.LA.TEK.COM
This is all very true, unfortunately, my original message had a
thinko. What I think would be useful is to have a set of standard
function names that are reserved and not mutable by the user.
Continuing the thinko, I should have said "%standard-" instead of
"%primitive-".
Why do I like this?
It is possible in the current scheme semantics to permanently lose all
of the user-visible bindings to a standard function. While this is
from the perspective of non-fascism desirable, it also means that
low-level "system"-type code basically can't trust anything at all.
There are two reasons why we might want to think about introducing
immutable things like
%standard-car
%standard-cdr
...
1. To be able to recover bindings to the standard functions
2. To be able to write low-level code that really does know what it is getting.
I observe as a side note that introducing environments would solve the
problem, but that idea seems to cause a lot of pain in these parts.
In the absence of such a mechanism, I am putting this forth as an
alternative to think about.
The fact that there is no way that my code can feel safe about its
standard environment is a serious weakness in scheme from the
standpoint of implementation. I wouldn't want to give up the
mutability, but it would be awfully nice to be able to know what world
my code is living in.
As to mutability, you missed the issue of optimization, which is a
significant one in my view.
Ciao.
Jon
∂29-Jun-89 2129 @mc.lcs.mit.edu,@relay.cs.net,@mojave.stanford.edu:shap@sid.stanford.edu A month of mail...
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 29 Jun 89 21:29:49 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa26830;
30 Jun 89 0:05 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 29 Jun 89 23:40:16 EDT
Received: from RELAY.CS.NET by mintaka.lcs.mit.edu id aa26257;
29 Jun 89 23:37 EDT
Received: from mojave.stanford.edu by RELAY.CS.NET id aa10029;
29 Jun 89 23:36 EDT
Received: from sid.Stanford.EDU by mojave.Stanford.EDU (5.59/inc-1.0)
id AA08968; Thu, 29 Jun 89 20:32:48 PDT
Message-Id: <8906300332.AA08968@mojave.Stanford.EDU>
Received: by sid; Thu, 29 Jun 89 20:35:27 pdt
Date: Thu, 29 Jun 89 20:35:27 pdt
From: "Jonathan S. Shapiro" <shap@sid.stanford.edu>
To: kend%bloom.la.tek.com@relay.cs.net
Cc: rrrs-authors%mc.lcs.mit.edu@relay.cs.net
In-Reply-To: kend%bloom.la.tek.com@relay.cs.net's message of Thu, 29 Jun 89 09:35:58 PDT <8906291636.AA12503@bloom.LA.TEK.COM>
Subject: A month of mail...
HOLD THE FIRE!
I just reread Ken's note. Yes, we need environments.
Jon
∂30-Jun-89 1052 @mc.lcs.mit.edu:chaynes@iuvax.cs.indiana.edu Draft agenda for 3rd IEEE Scheme standard meeting
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 30 Jun 89 10:52:46 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa04440;
30 Jun 89 13:47 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 30 Jun 89 13:44:31 EDT
Received: from IUVAX.CS.INDIANA.EDU by mintaka.lcs.mit.edu id aa04385;
30 Jun 89 13:43 EDT
Received: by iuvax.cs.indiana.edu
Date: Fri, 30 Jun 89 12:43:32 -0500
From: Chris Haynes <chaynes@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: Draft agenda for 3rd IEEE Scheme standard meeting
Message-ID: <8906301343.aa04385@mintaka.lcs.mit.edu>
A draft agenda follows for third meeting of the Scheme Working Group,
July 7th, 9:30am-5pm, Cambridge, MIT (room to be announced soon).
Suggestions for other agenda items are welcome.
1. Approve agenda.
2. Elect secretary.
3. Approve minutes of second meeting.
4. Discuss the numbers section of the standard draft.
5. Discuss proposals for differences between R4RS and the standard.
6. Discuss liaison with ISO WG-16. The question is whether we want to
formally submit a draft of our standard to the International
Standards Organization Lisp Working Group so that they may consider
the possibility of adopting our standard as an ISO standard. If we
decide to to submit, we must also draft an accompanying statement.
7. Establish time and place of next meeting.
∂30-Jun-89 1229 @mc.lcs.mit.edu:jinx@ZURICH.ai.mit.edu Location for 3rd IEEE Scheme standard meeting
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 30 Jun 89 12:28:55 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa05495;
30 Jun 89 15:12 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 30 Jun 89 15:06:43 EDT
Received: from [18.43.0.171] by mintaka.lcs.mit.edu id aa05271;
30 Jun 89 15:01 EDT
Return-Path: <jinx@ZURICH.AI.MIT.EDU>
Received: by ZURICH.AI.MIT.EDU; Fri, 30 Jun 89 14:58:26 edt
Date: Fri, 30 Jun 89 14:58:26 edt
From: "Guillermo J. Rozas" <jinx@ZURICH.ai.mit.edu>
Message-Id: <8906301858.AA19407@ZURICH.AI.MIT.EDU>
To: scheme-standard@ZURICH.ai.mit.edu
Cc: rrrs-authors@ZURICH.ai.mit.edu
Subject: Location for 3rd IEEE Scheme standard meeting
The room for the meeting on July 7th will be MIT room 37-252.
This room is called the Marlar Lounge, but few people know this, so
you should ask for 37-252 if lost.
Building 37's street address is
70 Vassar st. in Cambridge.
∂30-Jun-89 1535 @mc.lcs.mit.edu,@relay.cs.net,@tektronix.tek.com:kend@tekchips.labs.tek.com R↑3.95RS: open-input-file open-output-file
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 30 Jun 89 15:35:30 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa07943;
30 Jun 89 18:25 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 30 Jun 89 18:22:10 EDT
Received: from RELAY.CS.NET by mintaka.lcs.mit.edu id aa07857;
30 Jun 89 18:18 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa11414; 30 Jun 89 18:18 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
id AA17223; Fri, 30 Jun 89 15:19:54 PDT
Received: by tekirl.LABS.TEK.COM (5.51/7.0)
id AA11465; Fri, 30 Jun 89 15:16:30 PDT
Received: by tekchips.LABS.TEK.COM (5.51/6.24)
id AA05379; Fri, 30 Jun 89 15:19:14 PDT
Message-Id: <8906302219.AA05379@tekchips.LABS.TEK.COM>
To: rrrs-authors@mc.lcs.mit.edu
Cc: kend@mrloog.la.tek.com
Subject: R↑3.95RS: open-input-file open-output-file
Date: 30 Jun 89 15:19:12 PDT (Fri)
From: kend@tekchips.labs.tek.com
Both OPEN-INPUT-FILE and OPEN-OUTPUT-FILE are specified to `signal an
error' on failure. I would either like these to return #f on failure
or have 2 similar functions with such a behavior. The reason is for
programattic error recovery. As we do not yet have a standard error
system, I don't have a portable way within a (non-interactive) program
to recover from failure to open a file. On the other hand, it is
fairly easy for me to adapt to various error systems to signal an
error.
(define (OPEN-INPUT-FILE <filename>)
(let ( (port (%primitive-open-input-file <filename>)) )
(if port ; #f on failure
port
(system-specific-error "Can't open file \"~A\" for input"
<filename>)
) ) )
I can see the argument that returning #f or some such can be
interpreted as signalling an error, but I would prefer something I can
reliably use in a conditional and a behavior which is guarenteed not
terminate my [batch, system, etc] program. Even "(not (input-port?
port))" is something I can test [although I would prefer #f].
Does anyone remember the rationale for this?
-Ken kend@mrloog.LA.TEK.COM
∂30-Jun-89 2123 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #149
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 30 Jun 89 21:23:39 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa00507;
1 Jul 89 0:18 EDT
Date: 1 JUL 89 00:08:33 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #149
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID: <8907010018.aa00507@mintaka.lcs.mit.edu>
Scheme Digest #149 1 JUL 89 00:08:33 EDT
Today's Topics:
PC-Scheme
Draft agenda for 3rd IEEE Scheme standard meeting
Learning Scheme as a first language
----------------------------------------------------------------------
Date: Friday, 30 June 1989 08:55:44 TUR
From: Oguz ALGAN <ETIFIZ02%TREARN.BITNET@mitvma.mit.edu>
Subject: PC-Scheme
Message-ID: <8906300940.aa01822@mintaka.lcs.mit.edu>
Hello,
I want to learn the current version of the Texas Instrument's PC-Scheme Lisp.
And Do you know how can obtain the PC-Scheme's REFERANCE MANUAL or a book
that tells me about PC-SCHEME's language features.
Thanks in advance.
Oguz ALGAN,
ETIFIZ02@TREARN
------------------------------
Date: Fri, 30 Jun 89 12:35:31 -0500
From: Chris Haynes <chaynes@iuvax.cs.indiana.edu>
Subject: Draft agenda for 3rd IEEE Scheme standard meeting
Message-ID: <8906301335.aa04323@mintaka.lcs.mit.edu>
A draft agenda follows for third meeting of the Scheme Working Group,
July 7th, 9:30am-5pm, Cambridge, MIT (room to be announced soon).
Suggestions for other agenda items are welcome.
1. Approve agenda.
2. Elect secretary.
3. Approve minutes of second meeting.
4. Discuss the numbers section of the standard draft.
5. Discuss proposals for differences between R4RS and the standard.
6. Discuss liaison with ISO WG-16. The question is whether we want to
formally submit a draft of our standard to the International
Standards Organization Lisp Working Group so that they may consider
the possibility of adopting our standard as an ISO standard. If we
decide to to submit, we must also draft an accompanying statement.
7. Establish time and place of next meeting.
------------------------------
Date: 28 Jun 89 17:10:22 GMT
From: Dave McKellar <jarvis.csri.toronto.edu!utgpu!utzoo!yunexus!intacc!mckellar@rutgers.edu>
Subject: Learning Scheme as a first language
Message-Id: <1989Jun28.131023.1031@intacc.uucp>
Does anyone know of an easy-reading book about scheme.
If there is one I hope to use it as a text for a course
teaching scheme as a first computer language.
Please e-mail any reply to me as I dont read the news
regularly. I will post a summary if there is any
response. Thanks alot.
--
----------
{uunet,watmath,utzoo}!mnetor!intacc!mckellar "Taste is a matter of taste."
----------
------------------------------
End of Scheme Digest
********************
∂01-Jul-89 0447 @mc.lcs.mit.edu:jinx@ZURICH.ai.mit.edu R↑3.95RS: open-input-file open-output-file
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 1 Jul 89 04:47:14 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa04689;
1 Jul 89 7:41 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 1 Jul 89 07:38:38 EDT
Received: from [18.43.0.171] by mintaka.lcs.mit.edu id aa04621;
1 Jul 89 7:34 EDT
Return-Path: <jinx@ZURICH.AI.MIT.EDU>
Received: by ZURICH.AI.MIT.EDU; Sat, 1 Jul 89 07:31:50 edt
Date: Sat, 1 Jul 89 07:31:50 edt
From: "Guillermo J. Rozas" <jinx@ZURICH.ai.mit.edu>
Message-Id: <8907011131.AA22190@ZURICH.AI.MIT.EDU>
To: kend@tekchips.labs.tek.com
Cc: rrrs-authors@mc.lcs.mit.edu, kend@mrloog.la.tek.com
In-Reply-To: kend@tekchips.labs.tek.com's message of 30 Jun 89 15:19:12 PDT (Fri) <8906302219.AA05379@tekchips.LABS.TEK.COM>
Subject: R↑3.95RS: open-input-file open-output-file
Date: 30 Jun 89 15:19:12 PDT (Fri)
From: kend@tekchips.labs.tek.com
Both OPEN-INPUT-FILE and OPEN-OUTPUT-FILE are specified to `signal an
error' on failure. I would either like these to return #f on failure
or have 2 similar functions with such a behavior. The reason is for
programattic error recovery. As we do not yet have a standard error
system, I don't have a portable way within a (non-interactive) program
to recover from failure to open a file. On the other hand, it is
fairly easy for me to adapt to various error systems to signal an
error.
(define (OPEN-INPUT-FILE <filename>)
(let ( (port (%primitive-open-input-file <filename>)) )
(if port ; #f on failure
port
(system-specific-error "Can't open file \"~A\" for input"
<filename>)
) ) )
I can see the argument that returning #f or some such can be
interpreted as signalling an error, but I would prefer something I can
reliably use in a conditional and a behavior which is guarenteed not
terminate my [batch, system, etc] program. Even "(not (input-port?
port))" is something I can test [although I would prefer #f].
Does anyone remember the rationale for this?
-Ken kend@mrloog.LA.TEK.COM
I'd rather see new procedures which probe read/write accesibility of
files. One of the things I detest about the C culture is the
convention that procedures return 0 (or -1 sometimes) when things
fail, and never generate errors. Although a conscientious programmer
will write reasonable code given this convention, I think that it
strongly encouages carelessness and poor coding (errors propagate and
are not "detected" until much later, when the program "core dumps").
I would therefore oppose changing these procedures, or even
introducing virtually identical ones that return #f.
∂01-Jul-89 2126 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #150
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 1 Jul 89 21:26:46 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa11262;
2 Jul 89 0:17 EDT
Date: 2 JUL 89 00:08:30 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #150
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID: <8907020017.aa11262@mintaka.lcs.mit.edu>
Scheme Digest #150 2 JUL 89 00:08:30 EDT
Today's Topics:
Location for 3rd IEEE Scheme standard meeting
----------------------------------------------------------------------
Date: Sat, 1 Jul 89 07:32:26 edt
From: "Guillermo J. Rozas" <jinx@ZURICH.ai.mit.edu>
Message-Id: <8907011132.AA22198@ZURICH.AI.MIT.EDU>
Subject: Location for 3rd IEEE Scheme standard meeting
The room for the meeting on July 7th will be MIT room 37-252.
This room is called the Marlar Lounge, but few people know this, so
you should ask for 37-252 if lost.
Building 37's street address is
70 Vassar st. in Cambridge.
------------------------------
End of Scheme Digest
********************
∂02-Jul-89 1434 @mc.lcs.mit.edu,@mojave.stanford.edu:shap@sid.stanford.edu R↑3.95RS: open-input-file open-output-file
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 2 Jul 89 14:33:57 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa18131;
2 Jul 89 17:26 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 2 Jul 89 17:23:57 EDT
Received: from Mojave.Stanford.EDU by mintaka.lcs.mit.edu id aa18104;
2 Jul 89 17:22 EDT
Received: from sid.Stanford.EDU by mojave.Stanford.EDU (5.59/inc-1.0)
id AA12753; Sun, 2 Jul 89 14:19:54 PDT
Message-Id: <8907022119.AA12753@mojave.Stanford.EDU>
Received: by sid; Sun, 2 Jul 89 14:22:27 pdt
Date: Sun, 2 Jul 89 14:22:27 pdt
From: "Jonathan S. Shapiro" <shap@sid.stanford.edu>
To: jinx@ZURICH.ai.mit.edu
Cc: kend@tekchips.labs.tek.com, rrrs-authors@mc.lcs.mit.edu,
kend@mrloog.la.tek.com
In-Reply-To: "Guillermo J. Rozas"'s message of Sat, 1 Jul 89 07:31:50 edt <8907011131.AA22190@ZURICH.AI.MIT.EDU>
Subject: R↑3.95RS: open-input-file open-output-file
I agree with jinx. Having procedures return out-of-bound return
values to signal an error encourages all sorts of bad programming
habits, and has the further unfortunate property that it forces the
error detection/recovery code to be propagated to all of the calls if
I want to be well behaved.
In the absence of an error mechanism, though, it would be useful to
have an interim solution for people who need to write programs.
Writing a probing function doesn't get the job done - there is a race
condition between the time the file is probed and the time the open
happens. Ultimately, what is needed is the ability to pass a recovery
continuation to the open procedure so that one has a chance to come
back on failure.
Unfortunately this opens several cans of worms:
1. What should the error mechanism be [I like passing an error
continuation, but you may not.]
2. How can we standardize the set of possible errors so that
the error continuation can do something useful?
3. How do we decide which errors are recoverable.
I think that each of these issues takes considerable thought to get
right.
I would be interested to learn what mechanisms people have
experimented with and how well they work.
Jon
∂02-Jul-89 2200 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #151
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 2 Jul 89 22:00:35 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa21144;
3 Jul 89 0:46 EDT
Date: 3 JUL 89 00:09:16 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #151
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID: <8907030046.aa21144@mintaka.lcs.mit.edu>
Scheme Digest #151 3 JUL 89 00:09:16 EDT
Today's Topics:
OOP in Scheme
----------------------------------------------------------------------
Date: 2 Jul 89 07:31:07 GMT
From: Brian of ASTD-CP <brian@jade.berkeley.edu>
Subject: OOP in Scheme
Message-Id: <1404@jato.Jpl.Nasa.Gov>
; methods2.scm
;
; ===============================================================
; Brian Beckman | brian@topaz.jpl.nasa.gov
; Mail Stop 510-202 | (818) 397-9207
; Jet Propulsion Laboratory |
; Pasadena, CA 91109 | 30 June 1989
; ===============================================================
; INTRODUCTION
;
; This is a tiny object-oriented programming system with multiple
; inheritance and error handling. It is modeled after the message
; passing modules in Chapter 3 of Abelson & Sussman. It is
; implemented in ``pure'' Scheme, without macros or syntax
; extensions.
;
; This programming system is implemented as a technique, or
; programming convention, with some helper routines. The programming
; convention is not enforced, as we choose to avoid syntax-extensions
; for portability's sake. The technique is illustrated in this file
; with a few examples. In example one, a parent class, named
; ``parent,'' passes its attributes to a child named ``child.'' In
; example two, two parents, ``mother'' ``fater'', pass their attributes
; to a child class, ``daughter.'' The reader will perceive the technique
; by generalization from these examples and will be able to apply it
; to his or her own problems.
;
; Every class is represented by its constructor procedure. This
; procedure returns a message dispatching procedure. The message
; dispatching procedure should be named ``self'' so that an object can
; conveniently send messages to itself. However, ``self'' is an
; internal name not known outside the constructor.
;
; In summary, classes are represented by constructor procedures, and
; objects, or instances of classes, are represented by message
; dispatching procedures. The present version of ``methods'' does not
; support code sharing, so every instance of a class has its own
; private copies of the method code. We expect to implement code
; sharing in a later version of ``methods''.
;
; The message dispatching procedure walks the multiple inheritance
; hierarchy upwards until it finds an object that can understand a
; message, starting with itself. If no object that can understand the
; message is found, a global error procedure is called.
;
; IMPLEMENTATION
;
; Error processing is challenging. We should like to have two modes.
; In ``normal mode'', an error is reported only by the first receiver
; of a message. In ``debug mode'', an inheritance traceback should be
; given whereby every object in an inheritance hierarchy will report
; when it fails to recognize a given message. The following variable
; represents that mode. (For simplicity, this object is hidden only
; by its name, which is unusual enough that it is unlikely to be
; trammeled by an application. This is not the recommended technique
; for data hiding. Data hiding ought to be implemented through the
; techniques shown in this file! However, since this error handling
; part of the methods package is considered system programming,
; certain liberties in style are justifiable. There are in fact, good
; technical reasons for the error handling code to be implemented with
; global variables, which the perceptive reader will be able to
; deduce.)
(define **method-mode** 'normal-method-mode)
; The user can set these modes as follows.
(define (set-debug-method-mode)
(set! **method-mode** 'debug-method-mode))
(define (set-normal-method-mode)
(set! **method-mode** 'normal-method-mode))
(define (reset-debug-method-mode) ;;; synonym
(set! **method-mode** 'normal-method-mode))
; and test them with the following routine:
(define (test-debug-method-mode)
(eq? **method-mode** 'debug-method-mode))
; Before presenting the examples of classes and objects, some helper
; routines are needed.
;
; When an object cannot recognize a message, and none of its ancestor
; objects can recognize it, the object creates an error procedure and
; returns it as the result of the message dispatcher.
(define **method-error-class-name** "No class name.")
(define **method-error-message** 'no-message)
(define (error-method . junk-args)
(display **method-error-class-name**)
(display ": uknown message: '")
(display **method-error-message**)
(newline)
())
(define (make-error-method class-name msg)
(set! **method-error-class-name** class-name)
(set! **method-error-message** msg)
error-method)
; The procedure that walks the inheritance hierarchy must cooperate
; in the error handling.
(define (search-supertypes supers msg)
(define method ())
(if (test-debug-method-mode)
(begin
(display "Searching...")
(newline)))
(cond
( (null? supers) () )
( (begin
(set! method ((car supers) msg))
(eq? method error-method))
(if (test-debug-method-mode)
(error-method))
(search-supertypes (cdr supers) msg) )
( else method )))
; This procedure implements the inheritance of methods. It is greatly
; complicated by proper error handling. Without error handling, the
; routine would resemble the following, which is much easier to
; understand (without error handling, the programming convention is
; that an object that does not understand a message returns the
; unexecutable method ``()'').
;
; (define (search-supertypes supers msg)
; (cond
; ( (null? supers) () )
; ( ((car supers) msg) )
; ( else (search-supertypes (cdr supers) msg) )))
;
; The actual routine, with proper error handling, works as follows. A
; local variable, ``method'', is defined. Its value is not important
; to begin with. If debugging is on, we print a message telling the
; user that the inheritance hierarchy is being searched. Then, the
; list of supertypes is investigated. If the list is empty, we return
; nil, which signals the caller to create and return the error-method,
; as we shall see in the examples later. If the list is not empty, we
; pass the message to the first supertype in the list. The return
; value is assigned to the local variable ``method''. If the returned
; method is the one and only global error-method, then the supertype,
; and, recursively, all its supertypes, did not know the message.
; If debugging is on, we execute the returned error-method, contributing
; to the aforementioned inheritance traceback. Finally, we return
; the value of a recursive call of search-supertypes on the remainder
; of the list of supertypes. If the returned method is not the
; error-method, then the supertype did understand the message after
; all somewhere in the hierarchy, and the returned method is the
; return value of this procedure.
;
; Note that the list of supertypes is searched in order from front
; to back. The first match of a message results in the successful
; finding of a method. The order of supertypes in the list is
; significant only when more than one supertype can understand
; a given message. The earlier members of the list will shadow
; the later ones. In some object-oriented programming systems, one
; refers to the ``overriding'' of methods. The shadowing in
; ``methods'' is our form of method overriding, and it is under
; explicit control of the programmer who sets the order of supertypes
; in the list of supertypes.
;
; In summary, search-supertypes passes the message to the ancestors,
; in pre-order, returning the first method found.
;
; The next helper routine passes a message, and a variable number of
; arguments, to all the parents of an object. For side effects, it
; executes any methods found. Parents are defined as
; first level ancestors.
(define (for-all-parents supers msg . args)
(let ( (method-list
(map (lambda (supertype) (supertype msg)) supers))
(for-proc
(lambda (method) (apply method args))) )
(for-each for-proc method-list)))
; With the current programming convention, it is not possible to pass
; a message to all ancestors and execute the methods for side-effect
; without explicit cooperation on the part of the objects involved. In
; other words, the procedure ``for-all-ancestors'', analogous to
; ``for-all-parents'', cannot be implemented in the current version of
; the methods package. The reason is that the convention calls for
; every class to call ``search-supertypes'', which stops when it finds
; a method. The convention would have to be augmented so that objects
; would call ``find-all-methods'' (defined below) on an appropriate
; message. Since we expect the need for ``for-all-ancestors'' to be
; fairly rare, the necessary changes to the methods package will be
; reserved for a future version.
(define (find-all-methods supers msg)
(cond
( (null? supers) () )
( else (cons ((car supers) msg)
(find-all-methods (cdr supers) msg)) )))
; EXAMPLES (cut here to end of file to throw examples away)
;
; Our first example class, or object type, is ``parent'', represented
; by the following constructor procedure.
(define (new-parent arg)
(let ((state-var (* arg arg))
(supers ()))
(define (report-state-var)
(display state-var)
(newline)
state-var)
(define (update-state-var arg)
(set! state-var (* arg arg)))
(define (echo arg)
(display arg) (newline))
(define (self msg)
(cond
( (eq? msg 'report) report-state-var )
( (eq? msg 'update) update-state-var )
( (eq? msg 'echo) echo )
( (search-supertypes supers msg) )
( else (make-error-method "Parent" msg) )))
self))
; This class, or constructor procedure, completely illustrates, by
; example, the programming convention of the ``methods'' technique.
; The constructor takes a single argument, whose square it stores in a
; local state variable. Another state variable, the list of
; supertypes, is set to nil, since this class is at the root of an
; inheritance hierarchy. Three methods are defined, one that reports
; and returns the current value of the state variable, one that sets
; the state variable equal to a new square, and one that merely echoes
; its argument. A method dispatching procedure, conventionally named
; ``self'', tests a given message against three symbols and returns
; the corresponding method if a match is found. If no match is found,
; the list of supertypes is searched for a match. In the case of this
; class, ``parent'', the search is purely formal, to illustrate how it
; should be done, since ``parent'' has no ancestors. However, if a
; match were found among the list of supertypes, the method would be
; returned. Note how the search relys on the fact that any non-nil
; result is treated as a successful ``cond'' clause, terminating the
; ``cond'' statement. Search-supertypes returns nil only when a match
; is not found. Finally, if no match is found locally or among the
; supertypes, an appropriate error-method is pseudo-created and
; returned.
;
; We now test this class by making an instance and passing it
; messages.
(define p (new-parent 42))
((p 'report))
((p 'update) 69)
((p 'report))
((p 'echo) (list 1 2 3))
; We test error handling:
((p 'bogus))
(set-debug-method-mode)
((p 'bogus))
(reset-debug-method-mode)
((p 'bogus) 'here 'are 'some 'junk 'arguments)
; Continuing this example, let us define a child class inheriting
; all attributes and methods of the parent. Note the attributes of
; the parent are only accessible through the parent's method
; discipline. This is a strict form of inheritance, and the default
; in C++, for example. (C++ allows the programmer to override
; ancestors' access discipline, at his own peril.)
(define (new-child arg1 arg2)
(let* ( (leg1 (* arg1 arg1))
(leg2 (* arg2 arg2))
(hypotenuse (+ leg1 leg2))
(supers (list
(new-parent hypotenuse))) )
(define (report)
(for-all-parents supers 'report)
(display "Leg1 = ") (display (sqrt leg1)) (newline)
(display "Leg2 = ") (display (sqrt leg2)) (newline)
(display "Hypo = ") (display (sqrt hypotenuse)) (newline))
(define (update-leg1 val)
(set! leg1 (* val val))
(set! hypotenuse (+ leg1 leg2)))
(define (update-leg2 val)
(set! leg2 (* val val))
(set! hypotenuse (+ leg1 leg2)))
(define (self msg)
(cond
( (eq? msg 'report) report )
( (eq? msg 'update-leg1) update-leg1 )
( (eq? msg 'update-leg2) update-leg2 )
( (search-supertypes supers msg) )
( else (make-error-method "Child" msg) )))
self))
; We now test the child type.
(define c (new-child 3 4))
((c 'report)) ;;; passes message to all parents
((c 'update-leg1) 5)
((c 'update-leg2) 12)
((c 'report))
((c 'echo) '(foo bar)) ;;; msg known only in the parent
((c 'bogus) 'baz 'rat)
(set-debug-method-mode)
((c 'bogus) 'baz 'rat)
(reset-debug-method-mode)
((c 'bogus) 'baz 'rat)
; The last example, presented without detailed narrative, shows a
; slightly deeper inheritance hierarchy. The leaf is a type named
; ``daughter''. Its two parent classes are ``mother'' and ``father''.
; In turn, every mother has an ``estate'' and a ``religion'' (please
; excuse the somewhat strained metaphor of inheritance; this is just
; a little example).
(define (new-estate value)
(let ((value value)
(supers ()))
(define (report)
(display "Estate = $") (display value) (newline))
(define (what-value) value)
(define (increase amount) (set! value (+ value amount)))
(define (decrease amount) (set! value (- value amount)))
(define (self msg)
(cond
( (eq? msg 'report) report )
( (eq? msg 'what-estate) what-value )
( (eq? msg 'increase) increase )
( (eq? msg 'decrease) decrease )
( (search-supertypes supers msg) )
( else (make-error-method "Estate" msg) )))
self))
(define (new-religion theReligion)
(let ((religion theReligion)
(supers ()))
(define (report) (display "Religion = ") (display religion) (newline))
(define (what-religion) religion)
(define (convert theNewReligion) (set! religion theNewReligion))
(define (self msg)
(cond
( (eq? msg 'report) report )
( (eq? msg 'convert) convert )
( (eq? msg 'what-religion) what-religion )
( (search-supertypes supers msg) )
( else (make-error-method "Religion" msg) )))
self))
(define (new-father eye-color)
(let ((eye-color eye-color)
(supers ()))
(define (report) (display "Father's eye color = ")
(display eye-color) (newline))
(define (what-eye-color) eye-color)
(define (self msg)
(cond
( (eq? msg 'report) report )
( (eq? msg 'what-eye-color) what-eye-color )
( (search-supertypes supers msg) )
( else (make-error-method "Father" msg) )))
self))
(define (new-mother eye-color estate religion)
(let ((eye-color eye-color)
(supers (list
(new-estate estate)
(new-religion religion))))
(define (report)
(for-all-parents supers 'report)
(display "Mother's eye color = ")
(display eye-color) (newline))
(define (what-eye-color) eye-color)
(define (self msg)
(cond
( (eq? msg 'report) report )
( (eq? msg 'what-eye-color) what-eye-color )
( (search-supertypes supers msg) )
( else (make-error-method "Mother" msg) )))
self))
(define (new-daughter eye-color)
(let* ((eye-color eye-color)
(parents-eye-color
(if (eq? eye-color 'blue) 'blue 'brown))
(supers (list
(new-father parents-eye-color)
(new-mother parents-eye-color 500000 'Jewish))))
(define (report)
(for-all-parents supers 'report)
(display "Daughter's eye color = ")
(display eye-color)
(newline))
(define (what-eye-color) eye-color)
(define (self msg)
(cond
( (eq? msg 'report) report )
( (eq? msg 'what-eye-color) what-eye-color )
( (search-supertypes supers msg) )
( else (make-error-method "Daughter" msg) )))
self))
(define dbl (new-daughter 'blue))
((dbl 'report))
((dbl 'convert) 'muslim)
((dbl 'report))
((dbl 'increase) 50000)
((dbl 'report))
(define dbr (new-daughter 'brown))
((dbr 'report))
((dbr 'decrease) 250000)
((dbr 'report))
((dbr 'bogus))
(set-debug-method-mode)
((dbr 'bogus))
(reset-debug-method-mode)
------------------------------
End of Scheme Digest
********************
∂03-Jul-89 2219 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #152
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 3 Jul 89 22:19:37 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa03991;
4 Jul 89 1:09 EDT
Date: 4 JUL 89 00:09:20 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #152
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID: <8907040109.aa03991@mintaka.lcs.mit.edu>
Scheme Digest #152 4 JUL 89 00:09:20 EDT
Today's Topics:
OOP in Scheme (addendum)
AI NEWS FROM IEEE COMPUTER SOCIETY
Calculuses (sp?) for Scheme, and R*RS (again)
----------------------------------------------------------------------
Date: 3 Jul 89 08:16:05 GMT
From: Brian of ASTD-CP <brian@jade.berkeley.edu>
Subject: OOP in Scheme (addendum)
Message-Id: <1406@jato.Jpl.Nasa.Gov>
; methods.scm (ADDENDUM)
;
; ===============================================================
; Brian Beckman | brian@topaz.jpl.nasa.gov
; Mail Stop 510-202 | (818) 397-9207
; Jet Propulsion Laboratory |
; Pasadena, CA 91109 | 30 June 1989
; ===============================================================
; There are two ways to invoke a method in an object. The
; first is to send the object a message, getting back a procedure.
; This procedure can then be invoked at will on an appropriate
; set of arguments. Such an idiom usually results in expressions
; like the following:
;
; ((foo 'do-it) arg1 arg2)
;
; This is fairly readable and a fine idiom, but it has its
; limitations. Suppose that this expression were to result in
; another object, to which we should like to send the message
; 'baz with the arguments 'rat and 'ter. Then we should write
; the following:
;
; ((((foo 'do-it) arg1 arg2) 'baz) 'rat 'ter)
;
; The number of leading parentheses is a problem. It is easy
; to devise nested message passing expressions that are
; much more difficult to write than to devise, merely because of
; the number of leading parentheses that must be presaged. Lisp
; already has a problem with closing parentheses; we don't want
; to compound the felony in this package by introducing a
; corresponding problem with opening parentheses.
;
; We need a ``send'' routine that does little more than reduce
; the need for leading parenthese. This is, admittedly, merely
; a syntactic issue. Consider the following, which is the second
; way to send a message to an object:
(define (send object msg . args)
(apply (object msg) args))
; The earlier example message passing expressions can now be
; much more easly written much more nicely, as follows:
;
; (send object 'msg arg1 arg2)
;
; and
;
; (send (send object 'msg arg1 arg2) 'baz 'rat 'ter)
------------------------------
Date: Mon, 03 Jul 89 07:49 EDT
From: DYU%NCCIBM1.BITNET@mitvma.mit.edu
Subject: AI NEWS FROM IEEE COMPUTER SOCIETY
Message-ID: <8907030752.aa24699@mintaka.lcs.mit.edu>
WHAT IS THE TASK FORCE ON EXPERT SYSTEMS?
The IEEE Computer Society announces the formation of a
Task Force on Expert Systems Applications. The purpose of the
Task Force is to support interest in the development and use of
expert systems applications. The IEEE Computer Society, which
has over 100,000 members worldwide, authorized the creation of
the Task Force at a meeting of its Technical Activities Board
(TAB) held March 2nd in San Francisco, CA.
The objectives of the Task Force are to improve the
abilities of organizations and individuals to work with expert
systems technologies. The Task Force will sponsor activities at
the national and international levels, but also support local
events. The Task Force will publish a newsletter, exchange
electronic mail, provide speakers for conferences, organize
tutorials, symposiums, and convene meetings on standards either
on its own initiative or jointly with other IEEE Computer Society
functions.
The Importance of Expert Systems
MIS and end users are experiencing an explosion of
interest and activity in expert systems applications in almost
all sectors of business, government, and education. This is
taking place due to the wide distribution of expert system shells
on personal computers and workstations. It is a remarkable
change in the field of artificial intelligence in which
developers usually rely on specialized computer platforms and
programming languages.
Expert systems are the most mature and resilient products
to emerge from the AI community, and they are being adopted by
corporations and government departments to improve productivity.
They are doing this because the applications of expert systems to
specific knowledge intensive systems return high yields. Success
stories for expert systems are more common now than two years
ago. A current estimate is there are 2,000 operational expert
systems and 80% of them on running on personal computers.
The Value of the Task Force
The greatest value which will be derived from
participating in the Task Force will come from regular
discussions among Task Force participants. In some ways, this
will resemble the informal interactions of a user group. In
other ways it will compliment many of the professional activities
of the IEEE Computer Society.
Within these broad themes, there are many diverse
interests, including business activities such as banking and
finance, manufacturing and service functions, medical practice,
government functions, including the military, and education.
These interests will be addressed through locally sponsored and
nationally significant activities including conferences,
workshops, lectures, a newsletter, and other appropriate
mechanisms.
Membership
All meetings of the Task Force are be open to the public
and will be announced ahead of time in the news media. Anyone
who has an interest in the objectives of the Task Force is
invited to attend its functions and participate in its
activities. Membership in the IEEE Computer Society is not
required to attend our meetings. Since the Task Force is
oriented toward development and use of expert systems
applications, we expect and encourage the interest of vendors of
computer hardware, software, and services. Future activities of
the Task Force will be developed consistent with the goals and
objectives of the IEEE Computer Society.
For additional information, call Dan Yurman, Chairman, at
202-475-6754 9-5 EST. MCI Mail: 364-1277
Mailing address:
-----------------------------
Task Force on Expert Systems
c/o TAB Coordinator
IEEE Computer Society
1730 Massachusetts Ave., NW
Washington, DC 20036.
IEEE Computer Society
Task Force on Expert Systems
Roles & Responsibilities
Chair: This role is responsible for leadership and
technical direction of the Task Force. The Chair maintains the
vitality of the group by coordinating activities such as
speakers, seminars, conferences, workshops, tutorials, workgroups
on standards, and communications with members including
newsletters and electronic mail. The Chair appoints the other
leadership figures of the Task Force.
Dan Yurman, Chairman
Information Management Staff
Office of Solid Waste & Emergency Response
U.S. Environmental Protection Agency
401 M St., SW; (OS-110)
Washington, DC 20460 202-475-6754
Vice-Chairs: The Chair appoints Vice-Chairs for the
purpose of carrying out functions of the Task Force. All Vice
Chairs receive logistical support from the IEEE Computer
Society's administration office which is located in Washington,
DC. Vice-Chairs are responsible for recruiting volunteers to
carry out their responsibilities. Vice-Chairs are delegated the
authority to appoint such committee chairs as may be needed, e.g.
newsletter editor, workshop convener, etc.
Communications: Responsible for all communications with
members, the public, and other professional societies. Develops
and publishes a newsletter, establishes electronic mail exchange,
and sustains publicity for Task Force Events. Keeps a record of
all meetings. Serves as a point of contact with IEEE Expert
magazine and IEEE Computer magazine.
Sandra Hoffman, Vice Chair for Communications
Systems Analyst
Congressional Budget Office
2nd & D, SW; Room 450
Washington, DC 20515 202-226-2886
Meetings: Responsible for developing a program of
meetings featuring speakers on topics of interest to the
membership. Works with other Vice- Chairs to handle local
arrangements. Establishes working groups for tutorials and
seminars on significant topics.
Randy Manner, Vice Chair for Meetings
Manager - Expert Systems Group
American Management Systems
1777 N. Kent St.
Arlington, VA 22209 703-841-6849
Conferences: This Vice-Chair has a liaison role for the
IEEE Computer Society "Expert Systems in Government" Conference,
and for other IEEE Computer Society conferences which emphasize
applications of artificial intelligence and expert systems.
Also, this Vice Chair is responsible for coordinating the working
relationship of the Task Force with conferences on expert systems
sponsored by other professional societies.
Jerry Feinstein, Vice Chair for Conferences
Vice President
Phase-Linear Systems/ICF
9300 Lee Highway
Fairfax, VA 22031 703-934-3280
Standards: Develops working groups composed of users,
industry, and academia to address issues related to hardware or
software standards for expert systems applications.
Captain Dave Howell, Vice Chair for Standards
Artificial Intelligence
Program Management Office
U.S. Air Force Logistics Command
HQ AFLC/MM-AI
Wright Patterson AFB,
Ohio 45433 513-257-2571
Industry Relations: Establishes and maintains
communications with hardware and software vendors, developers,
and other commercial as well as not-for-profit providers of
expert systems applications. Provides for demonstration or
poster sessions on the latest technological developments.
Joseph Schmuller, Vice Chair for Industry Relations
Senior Knowledge Engineer
CDM Federal Programs Corp.
13135 Lee Jackson Highway
Fairfax, VA 22033 703-968-0900
Treasurer: Responsible for keeping track of Task Force
finances, for fund raising including setting up a means to cover
costs, and solicitations of "in kind" contributions.
Vacant
Membership: Responsible for developing and implementing
a membership recruitment campaign for the Task Force working at
the national level. Works with other Vice-Chairs to carry out
these functions. Establishes and maintains liaison with IEEE
Computer Society Chapters and Area Activities Boards as well as
other Task Forces and Technical Committees.
Vacant
Task Force on Expert Systems
c/o TAB Coordinator
IEEE Computer Society
1730 Massachusetts Ave. NW
Washington, DC 20036
---------------------------
Membership Mailing List and Activity Preference
NOTE: If you can't wait for the mail,
call a Vice Chair and volunteer today!
Please complete this form and return it to:
Dan Yurman, Chair
Task Force on Expert Systems
c/o US EPA (OS-110)
401 M St., SW
Washington, DC 20460
Ph: 202-475-6754
Please provide any suggestions or comments in the margins of the
paper. Thank you.
Name:________________________________________________________
Title:_______________________________________________________
Organization:________________________________________________
Address:_____________________________________________________
_____________________________________________________________
City:________________________________________________________
State: ______ ZIP:__________
Daytime Phone: ______ ______ ____________
Electronic mail:_____________________________________________
Please indicate the activities you would like to
volunteer your time and talents. You will be contacted soon.
You do not have to be a member of the IEEE Computer Society to
participate in the activities of the Task Force on Expert
Systems. At this time there is no charge to be placed on our
mailing list. Within the next six months there may be a nominal
dues charge to continue to receive these materials.
------------------------------
Date: 3 Jul 89 17:21:18 GMT
From: John Lacey <lacey@tcgould.tn.cornell.edu>
Subject: Calculuses (sp?) for Scheme, and R*RS (again)
Message-Id: <8313@batcomputer.tn.cornell.edu>
Does anyone have references to calculus bases for Scheme (such as
the lambda calculus, and the one by Matthias Felleisen)? That is,
references that deal with these directly in terms of Scheme (of
course those for the latter will, as it was designed for Scheme).
Also, I am *still* looking for the text of the Revised * Report on
Scheme. Where can I find it? Is there an E-mailable copy someplace?
Sorry about posting these types of questions, but the libraries here
are staffed with completely inadequate electronic searching systems,
and summer help.
--
John Lacey | Internet: lacey@tcgould.tn.cornell.edu
running unattached | BITnet: lacey@crnlthry
| UUCP: cornell!batcomputer!lacey
"Whereof one cannot speak, thereof one must remain silent." ---Wittgenstein
------------------------------
End of Scheme Digest
********************
∂04-Jul-89 1707 @mc.lcs.mit.edu,@relay.cs.net,@tektronix.tek.com:kend@bloom.la.tek.com R↑3.95RS: open-input-file open-output-file
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 4 Jul 89 17:07:37 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa11960;
4 Jul 89 20:06 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 4 Jul 89 20:03:43 EDT
Received: from RELAY.CS.NET by mintaka.lcs.mit.edu id aa11937;
4 Jul 89 20:02 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa06940; 4 Jul 89 20:02 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
id AA29240; Tue, 4 Jul 89 17:04:33 PDT
Received: by dadla.LA.TEK.COM (5.51/6.24)
id AA14612; Tue, 4 Jul 89 16:58:16 PDT
Received: from localhost.ARPA by bloom.LA.TEK.COM (1.2/6.24)
id AA16574; Tue, 4 Jul 89 17:03:03 pdt
Message-Id: <8907050003.AA16574@bloom.LA.TEK.COM>
To: jinx@ZURICH.ai.mit.edu, shap@sid.stanford.edu
Cc: rrrs-authors@mc.lcs.mit.edu
Subject: R↑3.95RS: open-input-file open-output-file
Date: Tue, 04 Jul 89 17:02:59 PDT
From: kend@bloom.la.tek.com
>> from Ken Dickey
> Both OPEN-INPUT-FILE and OPEN-OUTPUT-FILE are specified to `signal an
> error' on failure. I would either like these to return #f on failure
> or...
>> from JINX
> I'd rather see new procedures which probe read/write accesibility of
> files. One of the things I detest about the C culture is the
> convention that procedures return 0 (or -1 sometimes) when things
> fail, and never generate errors. Although a conscientious programmer
> will write reasonable code given this convention, I think that it
> strongly encouages carelessness and poor coding (errors propagate and
> are not "detected" until much later, when the program "core dumps").
> I would therefore oppose changing these procedures, or even
> introducing virtually identical ones that return #f.
I would very much like to see an error handling mechanism specified in
R↑5RS. In the interrum, is the Scheme community going to have a standard in
which a non-interactive program dumps core because of a failed file open?
Although legal behavior, I find this most distressing.
-Ken kend@mrloog.LA.TEK.COM
∂05-Jul-89 1411 @mc.lcs.mit.edu,@decwrl.pa.dec.com:jmiller@crl.dec.com Responses to a month of mail
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 5 Jul 89 14:11:29 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22410;
5 Jul 89 17:10 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 5 Jul 89 17:01:34 EDT
Received: from decwrl.pa.dec.com by mintaka.lcs.mit.edu id aa22221;
5 Jul 89 16:55 EDT
Received: from crl.crl.dec.com by decwrl.dec.com (5.54.5/4.7.34)
id AA03471; Wed, 5 Jul 89 13:55:01 PDT
Received: from crl.crl.dec.com by decwrl.dec.com (5.54.5/4.7.34)
for rrrs-authors@mc.lcs.mit.edu; id AA03471; Wed, 5 Jul 89 13:55:01 PDT
Received: by crl.crl.dec.com (5.57/Ultrix2.4-C)
id AA05480; Wed, 5 Jul 89 16:56:21 EDT
Date: Wed, 5 Jul 89 16:53:13 EDT
From: jmiller@crl.dec.com
Message-Id: <8907052053.AA00249@peanut.DEC.COM>
To: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Alan Bawden 29-Jun-89 1247 EDT's message of Thu, 29 Jun 89 12:59:40 EDT <8906291659.AA01277@crl.crl.dec.com>
Subject: Responses to a month of mail
Reply-To: JMiller%crl.dec@decwrl.pa.dec.com
I'd like to suggest that Pavel use "|" instead of ":" for his module
separator. It's currently illegal, and I believe that his argument
against its use (other dialects use it for an escape character) is
very weak. It also looks pretty good for just this purpose:
(module|submodule|procedure random-thing)
--Jim
∂05-Jul-89 1452 @mc.lcs.mit.edu,@decwrl.pa.dec.com:jmiller@crl.dec.com R↑3.95RS: open-input-file open-output-file
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 5 Jul 89 14:52:43 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22838;
5 Jul 89 17:40 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 5 Jul 89 17:12:00 EDT
Received: from decwrl.pa.dec.com by mintaka.lcs.mit.edu id aa22391;
5 Jul 89 17:09 EDT
Received: from crl.crl.dec.com by decwrl.dec.com (5.54.5/4.7.34)
id AA05041; Wed, 5 Jul 89 14:08:52 PDT
Received: from crl.crl.dec.com by decwrl.dec.com (5.54.5/4.7.34)
for rrrs-authors@mc.lcs.mit.edu; id AA05041; Wed, 5 Jul 89 14:08:52 PDT
Received: by crl.crl.dec.com (5.57/Ultrix2.4-C)
id AA05509; Wed, 5 Jul 89 17:10:29 EDT
Date: Wed, 5 Jul 89 17:07:22 EDT
From: jmiller@crl.dec.com
Message-Id: <8907052107.AA00259@peanut.DEC.COM>
To: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Jonathan S. Shapiro 2-Jul-89 1422 PDT's message of Sun, 2 Jul 89 17:36:32 EDT <8907022136.AA03775@crl.crl.dec.com>
Subject: R↑3.95RS: open-input-file open-output-file
Reply-To: JMiller@crl.enet.dec.com
At the risk of opening an entire can of worms, what about passing an
optional flag in to OPEN-... specifying (if present and EQ? to #T)
that a return value of #F is valid. Thus "ordinary" programming would
omit the flag and generate errors; users like Ken (?) would have the
control they would like.
--Jim
∂05-Jul-89 1835 @mc.lcs.mit.edu:Pavel.pa@xerox.com Re: R↑3.95RS: open-input-file open-output-file
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 5 Jul 89 18:35:52 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa25164;
5 Jul 89 21:27 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 5 Jul 89 20:58:50 EDT
Received: from [13.0.12.232] by mintaka.lcs.mit.edu id aa24767;
5 Jul 89 20:54 EDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JUL 89 17:53:42 PDT
Date: Wed, 05 Jul 89 17:53:24 PDT
From: Pavel.pa@xerox.com
Subject: Re: R↑3.95RS: open-input-file open-output-file
To: rrrs-authors@mc.lcs.mit.edu
Message-ID: <890705-175342-7490@Xerox>
I share the distaste of some others for returning special values to signal
errors or other exceptional conditions. I would, also as others have
stated, prefer that we agree on enough of a condition facility that such
errors can be handled that way. I have designed (if that's the right word
for something so simple) a condition facility that I believe contains
little enough policy that we might all agree on it in time for R4RS.
Unsurprisingly, however, it depends upon the existence of a mechanism for
fluid binding, so I will hold off on proposing the condition facility until
after we agree on fluid binding. I think that we can probably come to an
easy agreement on that issue at this point, so I will send out a proposal
either today or tomorrow to get the ball rolling.
Pavel
∂05-Jul-89 1856 @mc.lcs.mit.edu:Pavel.pa@xerox.com Curried definition syntax
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 5 Jul 89 18:56:37 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa25478;
5 Jul 89 21:53 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 5 Jul 89 21:49:38 EDT
Received: from Xerox.COM by mintaka.lcs.mit.edu id aa25369; 5 Jul 89 21:43 EDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JUL 89 18:12:04 PDT
Date: Wed, 05 Jul 89 18:11:57 PDT
From: Pavel.pa@xerox.com
Subject: Curried definition syntax
To: rrrs-authors@mc.lcs.mit.edu
Message-ID: <890705-181204-7527@Xerox>
I received only two responses to my proposal that we reinstate the
``curried'' syntax for definitions, dropped in the interval between RRRS
and R3RS. Both mentioned other possible extensions (type predicates on
arguments and variable-arity procedures) that might formally or
aesthetically clash with the additional syntax. Thus, at least until such
time as the fates of those possible extensions in the language are settled,
I'm willing to withdraw my proposal.
Pavel
∂05-Jul-89 1919 @mc.lcs.mit.edu:Pavel.pa@xerox.com Uniform definition semantics
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 5 Jul 89 19:19:29 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa25656;
5 Jul 89 22:06 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 5 Jul 89 21:49:47 EDT
Received: from Xerox.COM by mintaka.lcs.mit.edu id aa25395; 5 Jul 89 21:46 EDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JUL 89 18:44:39 PDT
Date: Wed, 05 Jul 89 18:44:30 PDT
From: Pavel.pa@xerox.com
Subject: Uniform definition semantics
To: rrrs-authors@mc.lcs.mit.edu
Message-ID: <890705-184439-7576@Xerox>
I proposed that the syntax and semantics of programs and ``bodies'' be
identical, with the following syntax and the more-or-less obvious
semantics.
<program> ::= { <expression> | <definition> | (begin <program>) }*
John Ramsdell supported this proposal while holding out his own more
conservative one as a possible fallback position.
Jinx agreed that internal and external definitions should have the same
semantics, but would rather that we instead adopt the current LETREC-style
semantics of internal definitions. He points out that this is ``too
radical to be accepted by most people'' and prefers the status quo to my
proposal (and presumably to John's as well).
I don't know that it is the ``radical'' nature of Jinx's preference that
keeps me from supporting it. Rather, it is the combination of great
incompatibility (I would bet that the vast majority of non-trivial existing
Scheme programs would become illegal) and great inconvenience. For
example, I frequently define a set of procedures for manipulating values of
some type and then immediately define another variable, initializing it via
a call on one or more of those procedures. Under Jinx's semantics, that
code would cease to be correct and would have to be rewritten, first
defining the variable to have some nonsense value and then assigning the
proper value to it in a separate expression. This is obfuscatory and
useless.
As to the status quo, I cannot agree that two conflicting semantics are
better than a single compatible, useful, and intuitive one.
The only other response came from Ken Dickey (I think that's his last
name), who said the following:
I like the internal semantics and would like to change the name of the
special form used in interactive loops from "define" to something else
(e.g.
"defun"). The top-level-environment is an artifact of an interactive
system. We could make a naming distinction between uses/behaviors,
rather
than changing uses because of a name alias.
See above for my comments on the internal semantics.
I do not agree that the top-level environment has anything to do with the
interactive nature of some Scheme implementations. It has more to do with
a notion of a global namespace, shared among many distinct program
fragments (often stored in files). As such, definitions are simply
another, sometimes more convenient, syntax for the establishment of a
lexical contour, completely unrelated to interactivity. Thus, I see no
difference in the uses of internal and external definitions and therefore
wish they had the same behavior.
I am surprised that there have been no other comments; is one to assume
that the remainder of the list has no opinion on the subject?
Pavel
∂05-Jul-89 1941 @mc.lcs.mit.edu:Pavel.pa@xerox.com Reserving a character for experimentation
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 5 Jul 89 19:41:43 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa25830;
5 Jul 89 22:26 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 5 Jul 89 22:05:43 EDT
Received: from Xerox.COM by mintaka.lcs.mit.edu id aa25624; 5 Jul 89 22:04 EDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JUL 89 19:04:11 PDT
Date: Wed, 05 Jul 89 19:04:03 PDT
From: Pavel.pa@xerox.com
Subject: Reserving a character for experimentation
To: rrrs-authors@mc.lcs.mit.edu
Message-ID: <890705-190411-7603@Xerox>
I think that Alan Bawden stated my position (and, in particular, my
reaction to some of the other comments on my proposal) quite completely and
adequately, so I'll answer only the comments since his note.
Ken Dickey (?) says:
The *problem* I see with making #\: reserved is in portability of the
above
systems. I may not have access to the implementation of Scheme which I
am
using. If I want to experiment with random-module-package and the
implementation of Scheme I am using treats #\: as a comment character, I
have to bash or rewrite the reader just to get the sources I want to try
out
to lex properly. If I can read symbols containing #\:, then I can
post-process the list structure which I can read using a standard
reader.
I am in a much better position for experimentation if I can portably
share
experiments without having to bash the implementation. Making #\:
reserved
works against this.
First, if the character is not reserved, then I cannot use it for anything
special in my implementation and remain compatible with the outside world.
Secondly, suppose that I use some other character, not currently legal in
identifiers, such as ``#''. Then you probably *still* can't read my code
into your implementation, since your reader will either barf at my uses of
the illegal character or, even worse, silently parse the code making some
entirely different implementation-specific interpretation of the character.
Thus, no matter how this issue goes, you probably can't trivially parse my
code in your implementation. Your argument is therefore moot.
Ken's message ended with the following line:
(mod1:foo 3 x mod2:bar) --> ((*value mod1 'foo) 3 x (*value mod2 bar))
This might be true in some T-like interpretation of structured names, but
since I reject first-class environments (on the basis of large program
robustness and the value of static checking), I cannot use such a
rewriting. Besides, it's appallingly verbose and unreadable for a
construct to be so commonly used. One might as well force us to say (quote
...) everywhere instead of the simpler ``lexical convention''.
Jim Miller suggests that I use ``|'' instead of colon. I considered it,
but found it less readable and far less culturally compatible than colon.
It seems silly to diverge from Common Lisp and Zetalisp on this convention
for so little reason. After all, how much code would have to change if we
reserved colon? None, since most implementations could simply choose to
``experiment'' with colon by allowing in identifiers, just as they do now.
Remember Alan's best point: this only affects the definition of what
programs are portable and does not force any implementation to change at
all.
Pavel
∂05-Jul-89 2048 @mc.lcs.mit.edu:Pavel.pa@xerox.com Assignment to standard variables
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 5 Jul 89 20:48:09 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa26499;
5 Jul 89 23:45 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 5 Jul 89 23:38:15 EDT
Received: from Xerox.COM by mintaka.lcs.mit.edu id aa26423; 5 Jul 89 23:36 EDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JUL 89 20:04:43 PDT
Date: Wed, 05 Jul 89 20:04:36 PDT
From: Pavel.pa@xerox.com
Subject: Assignment to standard variables
To: rrrs-authors@mc.lcs.mit.edu
Message-ID: <890705-200443-7674@Xerox>
The majority of responses recently have been to my proposal that it be an
error to assign to the standard variables, present in the so-called
``initial environment''.
Jinx's first message on this topic stated his opposition to the proposal on
the grounds that ``the user takes precedence over the system'', the meaning
of which he clarified in a subsequent message. There, he says:
... the system/implementation is a
tool for the user, and as such it should accomodate the wishes of the
user, not viceversa. Thus if a user wants to call CAR something he
writes/uses (in a Church pair implmentation, for example), he should
be allowed to do so.
I have two counterarguments to this. First, since the user cannot portably
assign to (or even rebind) variables named ``if'', ``or'', ``delay'', or
even ``unquote'' (uses of which cannot conflict with its assigned meaning),
the user has already lost this battle.
Second, I question the whole notion of ``user''. Your usage (and that of
most of the other respondents) implies that there is some human,
interactively manipulating the state of some Scheme implementation. This
vision of Scheme implementations is not universal. In particular, it is
easy for me to imagine Scheme systems with many ``users'' and none at all.
In a large system, simultaneously running the code of many programmers,
each of those hackers is a ``user'' in the sense that you mean. For any
one of them to decide to change the value of a standard variable would very
likely be disastrous for all of the others.
This is the value of lexical scoping. It is not necessary for that one
iconoclastic user to make an assignment to CAR; they can simply rebind that
name over the scope of their piece of code. That way, they're happy
because they can use what they see as intuitive names, and the other users
are happy because the standard variables have the predicted standard
values.
With things as they are, you cannot afford to load any code I might send
you into your running system; I might very well make every other
``user-level'' piece of code bomb completely.
The model of a single Scheme programmer sitting at his read-eval-print loop
running only his own small program cannot be the sole customer of this
language design, or else Scheme deserves the occasional claim that it is
but a ``toy'' language. If this is the goal of the bulk of the RRRS
authors, then please let me know; I'll go quietly. I sincerely hope it is
not.
Jinx also mentioned the use of declarations to allow compilers to process
uses of standard variables more efficiently. One should not have to work
in a modified language semantics in order to get reasonable efficiency. In
particular, it seems odd to resort to such semantically inconsistent
constructs just to retain the dubious right to assign to CAR.
In his second message, Jinx offered a ``pragmatic'' reason for opposing my
proposal:
Presumably you would like
implementations to be able to add new primitives to the language
described in the report. Given that the semantics of any programs
using them might be compromised in the same way that it would be when
using a "standard" primitive, you would disallow assignment and
redefinition of implementation-specific primitives as well. This
implies that portability can only be achieved by using obscure names
(ie G00034), since any "reasonable" name is potentially reserved by
some implementation.
R4RS already requires, in section 1.3.1, that every implementation provide
a ``syntactic mode that preempts no lexical conventions of this report and
reserves no identifiers'' other than those listed in the report. Such a
mode is explicitly included to ``support portable code''.
Morry Katz, in contrast, appears to be closer to supporting my proposal.
In his June 28 message on the subject, he says:
You did not request that an implementation be allowed to prohibit
redefinition of the primitives, but stated that you wanted redefinition
of a primitive to be an error.
He also says:
If you would like to propose something that allows your system to
consider redefinition an error but does not require my system
to do such, I might be willing to consider it.
When we state that a certain situation ``is an error'', we state that the
effect of achieving that situation is unspecified. In particular, if we
state that assigning to standard variables is an error, the effect in one
implementation might be that the assignment takes place without difficulty.
In another, an error might be signalled. In another, the compiler might
reject the program, noticing that the assignment expression cannot be
performed without signalling an error. The phrase ``is an error''
encompasses all of these possibilities. Thus, when I ask that we make
assignment to standard variables an error, I am, indeed, proposing
``something that allows [my] system to consider redefinition an error but
does not require [your] system to do such.'' This is the point I was
trying to make in my previous message on this topic. I was not attempting
to pervert Morry's meaning at all.
Morry also mentions declarations:
Nearly everyones compiler currently allows a compiler directive to the
effect
that primitives should be considered immutable and therefore
inlineable. This
has been done for the obvious efficiency reasons and does not require
that the
language specification be altered to always prohibit modifying
primitives.
It is to me a sign of the weakness of the current specification that
``nearly everyone'' feels the need to restrict the semantics in order to
generate reasonable code.
Pavel
∂05-Jul-89 2227 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #153
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 5 Jul 89 22:27:50 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa27565;
6 Jul 89 1:09 EDT
Date: 6 JUL 89 00:09:35 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #153
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID: <8907060109.aa27565@mintaka.lcs.mit.edu>
Scheme Digest #153 6 JUL 89 00:09:35 EDT
Today's Topics:
OOP in Scheme (serious example)
----------------------------------------------------------------------
Date: 5 Jul 89 21:47:32 GMT
From: Brian of ASTD-CP <brian@topaz.rutgers.edu>
Subject: OOP in Scheme (serious example)
Message-Id: <1412@jato.Jpl.Nasa.Gov>
; This'll be my last submission on this topic, so I promise I won't
; be burning up the wires with any more. I thought a serious
; example would be of some interest, however, so here is a FIFO
; queue data type. I'll be building classes for priority queues,
; heaps, splay trees, and assorted others, as well as a data flow
; executive. Anyone interested further in this topic may feel
; free to e-mail me. Again, sorry for the length of these sub-
; missions. BCB.
;================================================================
;| Brian Beckman | brian@topaz.jpl.nasa.gov |
;| Mail Stop 510-202 | (818) 397-9207 |
;| Jet Propulsion Laboratory | |
;| Pasadena, CA 91109 | 3 July 1989 |
;================================================================
;;; Adapted from Abelson & Sussman, Ch. 3, Pg 208 ff.
;;; Uses the ``methods'' OOP package. This is an expanded,
;;; industrial-strength solution to Exercise 3.22 of A & S.
(define (new-queue . initial-list)
(let ( (q (cons () ()))
(dummy (if (not (null? initial-list))
(set! initial-list (car initial-list))))
(supers ()) )
(define (head) (car q))
(define (tail) (cdr q))
(define (set-head! item) (set-car! q item))
(define (set-tail! item) (set-cdr! q item))
(define (empty-queue?) (null? (head)))
(define (front)
(if (send self 'empty?)
(error "FRONT called on empty queue")
(car (head))))
(define (insert-queue! item)
(let ((elt (cons item ()))) ; could be (list item)
(cond
( (send self 'empty?)
(set-head! elt)
(set-tail! elt)
self )
( else
(set-cdr! (tail) elt)
(set-tail! elt)
self ))))
(define (insert-list! lyst)
(cond
( (null? lyst) self )
( else
(send self 'insert! (car lyst))
(insert-list! (cdr lyst)) )))
(define (remove-queue!)
(cond
( (send self 'empty?)
(error "REMOVE called on empty queue") )
( else
(set-head! (cdr (head))) self)))
(define (clear-queue!)
(set! q (cons () ()))
self)
(define (print) (display (head)) (newline))
(define (self msg)
(cond
( (eq? msg 'insert!) insert-queue! )
( (eq? msg 'empty?) empty-queue? )
( (eq? msg 'remove!) remove-queue! )
( (eq? msg 'clear!) clear-queue! )
( (eq? msg 'front) front )
( (eq? msg 'print) print )
( (eq? msg 'list) (lambda () (head)) )
( (eq? msg 'insert-list!) insert-list! )
( (search-supertypes supers msg) )
( else (make-error-method "Queue" msg) )))
(insert-list! initial-list) ;;; returns ``self''
))
;;; end of new-queue
; Test suite for queues.
(define q (new-queue '(a b c d e)))
(send q 'print)
(send q 'list)
(send (send q 'remove!) 'print)
(send q 'empty?)
(send (send q 'clear!) 'empty?)
(send q 'print)
(define q (new-queue))
(send q 'empty?)
------------------------------
End of Scheme Digest
********************
∂05-Jul-89 2230 @mc.lcs.mit.edu:Pavel.pa@xerox.com Fluid binding
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 5 Jul 89 22:30:19 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa27623;
6 Jul 89 1:12 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 6 Jul 89 00:46:48 EDT
Received: from Xerox.COM by mintaka.lcs.mit.edu id aa27183; 6 Jul 89 0:44 EDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JUL 89 21:05:34 PDT
Date: Wed, 05 Jul 89 21:05:31 PDT
From: Pavel.pa@xerox.com
Subject: Fluid binding
To: rrrs-authors@mc.lcs.mit.edu
Message-ID: <890705-210534-7725@Xerox>
In conversations with several other members of this group, it has been
mentioned that there really isn't very much disagreement any longer on the
issue of fluid binding; it is usually noted that we simply need a concrete
proposal on which to agree. On this optimistic assumption, therefore, I
offer the following.
I hope that we can agree on the following points concerning fluid binding:
-- We want some kind of facility in the language that supports a form of
dynamic binding.
-- We do not want a Common Lisp-style two-namespace solution.
-- The binding construct has a syntax something like LET, in which a set of
expressions are evaluated in an unspecified order and their values used in
establishing new fluid bindings.
-- The extent of those bindings is dynamic, in the sense that they are in
effect exactly during the evaluation of the body of the binding form.
-- As a consequence, continuations created in that body should capture the
fluid environment and re-establish it upon invocation. Such
re-establishment should not involve re-evaluating the non-body expressions
in the binding form.
-- Upon exit from the body of the binding form, the bindings in effect
before entry to the form should be restored.
One of the most commonly-cited proposals for such a facility is described,
for example, in Kent Dybvig's book. In that facility, the so-called
``binding form'' in fact creates no bindings at all. Instead, it saves the
current values of the named lexically-visible variables, assigns new values
during the evaluation of the body, and restores the old ones after the body
is finished. This could be described implementationally as ``shallow
binding lexical variables''.
There are some problems with this idea for some implementations.
In a time-shared multiprocessing implementation, on each context switch the
set of bindings for each of the old and new running process must be
re-traversed, in order to properly save the old context and re-establish
the new.
Further, if two processes share a continuation, then one would expect that
when they share the captured fluid environment they also share the
``state'' of those bindings. For example, if a process fluid-binds a
particular variable, captures the continuation, modifies the variable, and
then forks a process invoking the newly-created continuation, I would hope
that the new process would ``see'' the new value of the shared fluid
binding. Of course, the two processes should also be able to communicate
by repeated assignments to the shared binding. I do not see how to
implement this.
Matters are even worse for a multiprocessor implementation (that is,
multiple instruction single data, such as on a Sequent or other
shared-memory multiprocessor). In this case, I can see no way to avoid the
use of deep binding to get the desired semantics. In a shallow bound
implementation, multiple processes will ``race'' for ``rebinding'' a shared
variable and ultimately lose horribly.
Given that some implementations will be forced to use deep binding, we
could simply consider using the same syntax and semantics as before, but
with a deep binding implementation. In such a situation, if a particular
variable might at some point be fluid-bound, then all references (both read
and write) would have to invoke the deep binding lookup mechanism. Since
this would, of necessity, include all global variables (since a compiler
can never claim to have seen all uses of a global variable, it must assume
the worst), I conclude that the performance degradation would be
unacceptable. (There are ways to make this a little better, such as adding
a bit to each such variable to say whether or not it has ever been
fluid-bound. If not, then the value must be in the global cell and the
expensive lookup can be avoided. It still sounds too slow to me.)
The problem here is that references to fluid-bound variables cannot, in
general, be lexically distinguished from references to non-fluid-bound
variables. My proposal, therefore, makes such a distinction, in a sense.
Having motivated the design, I now present it.
=========
(MAKE-FLUID obj) [Procedure]
Create and return a new ``fluid variable'' whose global value is obj.
(FLUID-REF fluid-variable) [Procedure]
Return the value of the given fluid-variable in the current fluid
environment.
(FLUID-SET! fluid-variable obj) [Procedure]
Change the value of the given fluid-variable in the current fluid
environment. The returned value is unspecified.
(FLUID-LET ((var-expr val-expr) ...) body) [Syntax]
Evaluate the var-exprs and val-exprs in an unspecified order; the var-exprs
should yield fluid variables. Return the value of the body in a new,
nested fluid environment in which the given fluid variables have new
bindings, initialized to the given values. This fluid environment has
precisely the same extent as the evaluation of the body and is thus
captured by continuations created within the body and re-established by
those continuations on invocation.
=========
The implementation is free to adopt either shallow or deep binding. In
either case, a ``fluid variable'' is simply a one-cell allocated datum
containing the value of the fluid variable either in the current fluid
environment (shallow binding) or in the global, top-level fluid environment
(deep binding). In either case, the address of the cell can be used as the
``identifier'' for the variable in the environment. This proposal, in
comparison to the one discussed before, increases the cost per reference in
a shallow-bound implementation by one memory reference, indirecting through
the cell-address. This seems a small price to pay.
The proposal is unusual in that the variable position in FLUID-LET is
evaluated, but I anticipate that in almost all uses the expression will be
a simple lexical variable reference:
(define *foo* (make-fluid 7))
(fluid-let ((*foo* 8))
(+ (fluid-ref *foo*) 1))
=> 9
Comments?
Pavel
∂05-Jul-89 2240 @mc.lcs.mit.edu:jinx@ZURICH.ai.mit.edu Assignment to standard variables
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 5 Jul 89 22:40:01 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa27843;
6 Jul 89 1:21 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 6 Jul 89 01:17:50 EDT
Received: from [18.43.0.171] by mintaka.lcs.mit.edu id aa27680;
6 Jul 89 1:14 EDT
Return-Path: <jinx@ZURICH.AI.MIT.EDU>
Received: by ZURICH.AI.MIT.EDU; Thu, 6 Jul 89 01:11:35 edt
Date: Thu, 6 Jul 89 01:11:35 edt
From: "Guillermo J. Rozas" <jinx@ZURICH.ai.mit.edu>
Message-Id: <8907060511.AA28668@ZURICH.AI.MIT.EDU>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Pavel.pa@xerox.com's message of Wed, 05 Jul 89 20:04:36 PDT <890705-200443-7674@Xerox>
Subject: Assignment to standard variables
I have two counterarguments to this. First, since the user cannot portably
assign to (or even rebind) variables named ``if'', ``or'', ``delay'', or
even ``unquote'' (uses of which cannot conflict with its assigned meaning),
the user has already lost this battle.
We've been trying to fix this for quite a while. It has not been
fixed in R4RS because of political and technical problems having to do
with the actual solutions suggested, not because we don't agree that
this should be fixed.
Second, I question the whole notion of ``user''. Your usage (and that of
most of the other respondents) implies that there is some human,
interactively manipulating the state of some Scheme implementation. This
vision of Scheme implementations is not universal. In particular, it is
easy for me to imagine Scheme systems with many ``users'' and none at all.
In a large system, simultaneously running the code of many programmers,
each of those hackers is a ``user'' in the sense that you mean. For any
one of them to decide to change the value of a standard variable would very
likely be disastrous for all of the others.
You misunderstand my argument in many ways:
1) By user I mean any programmer, not necessarily human. I would like
my program generating programs not to have to probe the underlying
implementation for the list of all unusable names, which is likely to
evolve as the implementation and the language evolve. Furthermore, I
would like not to have to rewrite my programs when/if R5RS comes out
just because a new procedure has been added to the report.
2) Redefinition does not imply assignment. In a scheme system with
first class environments, each user can get his own (initially
identical) first class environment in which he can redefine as he
pleases, without affecting anyone else. [This is what I consider
essential. I would not be terribly upset if we disallowed
(set! car ...) but would not tolerate disallowing (define car ...).]
Note that my position does not require first class environments, it
simply requires that each user's interactive environment be isolated
from what the system uses, and from what other users use if there are
multiple users. As I mentioned in another message, security of the
implementation is an implementation problem, not a language problem.
3) Even assignment of shared variables should be legal. Assignment of
shared variables is a double edged sword: It is potentially dangerous
(like anything powerful), but if used judiciously it provides a
wonderful way of debugging and patching running systems.
Think of the following analogy:
The environment tree is like a hierarchical file system (with path
inheritance). Each user has his own "home directory" where he can
name any file anything he wants, although shadowing the name where a
system provided utility resides may be inconvenient. On the other
hand, s/he can fix a bug in the C compiler (for example) by replacing
(assigning) the current file containing it. Operating systems need
the ability to replace system utilities because they are intended to
run for long periods of time and allow incremental patches. Please
don't remove such an ability from my favorite operating system! Your
suggestion would make Scheme too inflexible for long running evolving
applications.
This is the value of lexical scoping. It is not necessary for that one
iconoclastic user to make an assignment to CAR; they can simply rebind that
name over the scope of their piece of code. That way, they're happy
because they can use what they see as intuitive names, and the other users
are happy because the standard variables have the predicted standard
values.
Lexical scoping as it appears in the report does not solve the
problem. The top level environment allows me some debugging ability
(through interaction) which I don't have when I use any other
mechanism. If your implementation provides interaction (with
definition) in arbitrary environments, your implementation can solve
the isolation problem trivially.
Jinx also mentioned the use of declarations to allow compilers to process
uses of standard variables more efficiently. One should not have to work
in a modified language semantics in order to get reasonable efficiency. In
particular, it seems odd to resort to such semantically inconsistent
constructs just to retain the dubious right to assign to CAR.
Reasonable is a subjective term. I think it is perfectly possible to
obtain reasonable efficiency without declarations. Efficiency beyond
this may require concessions, and declarations are a small price to
pay. I would like to see a compiler that provides complete security,
complete debugability, and utmost efficiency without any form of
declaration, but I have not yet seen such a beast (nor do I think it
is possible to have one on stock hardware).
Again, although I think that the right to assign to CAR is important,
the one that I'm more concerned with is the right to DEFINE CAR. You
are viewing definition and assignment as the same thing, but in my
mind (and in the implementation that I use) they are not. If your
implementation and development environment are confused about this,
that's your implementor's problem, but please don't impose these
limitations on the language or my implementation.
You also seem to have shifted your argument from semantic
predictability to efficiency, and efficiency has never been important
when designing Scheme. The problem with efficiency as an argument in
language design is that it is a time dependent parameter, since it
depends on compilation technology and hardware, both of which change
quickly. Would you make the same efficiency argument about MAP that
you are making about CAR? What about LIST-TAIL or
CALL-WITH-CURRENT-CONTINUATION? Yet if I'm playing with streams I
would like to define MAP, and if I'm playing with interpreters I may
want to redefine CALL-WITH-CURRENT-CONTINUATION. In all but contrived
situations the efficiency lost from not open coding MAP or
CALL-WITH-CURRENT-CONTINUATION is minimal, so your efficiency argument
does not really stand up.
R4RS already requires, in section 1.3.1, that every implementation provide
a ``syntactic mode that preempts no lexical conventions of this report and
reserves no identifiers'' other than those listed in the report. Such a
mode is explicitly included to ``support portable code''.
I think most people would agree that R4RS as it currently stands is a
toy language. Besides macros, fluid binding and other well known
conveniences, it lacks any practical way of separating large programs
into semi-independent subprograms without exporting zillions of names
into the top level environment.
I think most implementations provide some way of solving or bypassing
these problems. Thus, until we solve these issues, R4RS is unusable
for large programs, and your argument doesn't help me at all.
Some day in the future, when we solve (if we can ever agree on
anything else) these problems, this may be an option, but almost any
facility that I can envision for separating and combining subprograms
will allow me to have my own definitions of anything I want.
I'm afraid we are going to disagree very strongly on this issue, and
therefore we are at an impasse. Unfortunately that seems to be
happening with everything else that anyone proposes, so I'm afraid
that R3.95RS is the end of the line. What a pity.
∂06-Jul-89 0713 @MC.lcs.mit.edu:jmiller@crl.dec.com Reserving a character for experimentation
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 6 Jul 89 07:13:39 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa03520;
6 Jul 89 10:09 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 6 Jul 89 10:04:27 EDT
Received: from [128.45.9.1] by mintaka.lcs.mit.edu id aa03471;
6 Jul 89 10:02 EDT
Received: from crl.crl.dec.com by decwrl.dec.com (5.54.5/4.7.34)
id AA09772; Thu, 6 Jul 89 07:01:41 PDT
Received: from crl.crl.dec.com by decwrl.dec.com (5.54.5/4.7.34)
for rrrs-authors@mc.lcs.mit.edu; id AA09772; Thu, 6 Jul 89 07:01:41 PDT
Received: by crl.crl.dec.com (5.57/Ultrix2.4-C)
id AA06722; Thu, 6 Jul 89 10:02:56 EDT
Date: Thu, 6 Jul 89 09:59:48 EDT
From: jmiller@crl.dec.com
Message-Id: <8907061359.AA00613@peanut.DEC.COM>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@MC.lcs.mit.edu
In-Reply-To: 5-Jul-89 1904 PDT's message of Wed, 5 Jul 89 22:49:11 EDT <8907060249.AA06354@crl.crl.dec.com>
Subject: Reserving a character for experimentation
Reply-To: JMiller@crl.enet.dec.com
Sorry, but I can't really see a valid argument for taking a character
already in use (not just presumably, but actually) in existing Scheme
code and reserving it because you prefer it over other choices already
available. I'm not a fan of lexical syntax, and I think the damage
caused to existing (possibly portable) code outweighs the possible
gains.
I don't understand the following comment:
After all, how much code would have to change if we reserved
colon? None, since most implementations could simply choose to
``experiment'' with colon by allowing in identifiers, just as
they do now.
It appears to me that this simply isn't true. Portable code would not
be permitted to use names with embedded colons, and such code already
exists. Perhaps what you meant is that no individual's code running
in an existing implementation would be affected -- but I'm more
worried about the portable code I've written over the years. I'd like
it to remain portable, and your suggesting one more headache to worry
about.
--Jim
P.S.: Another pair of suggestions, valid within the existing
framework. Other ideas along this line that would be more extensible
would be very interesting.
(module#:submodule#:procedure ...)
(procedure #!part-of submodule #!part-of module ...)
∂06-Jul-89 0730 @MC.lcs.mit.edu:sfk@hplb.hpl.hp.com Re: Fluid binding
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 6 Jul 89 07:30:48 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa03706;
6 Jul 89 10:24 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 6 Jul 89 10:20:31 EDT
Received: from hplb.hpl.hp.com by mintaka.lcs.mit.edu id aa03567;
6 Jul 89 10:14 EDT
Received: from sknight.hpl.hp.com by hplb; Thu, 6 Jul 89 15:04:42 bst
Message-Id: <8907061404.AA28845@otter.hpl.hp.com>
Received: by sknight; Thu, 6 Jul 89 15:01:12 bst
From: Steve Knight <sfk@hplb.hpl.hp.com>
Subject: Re: Fluid binding
To: Pavel.pa@xerox.com
Date: Thu, 6 Jul 89 15:01:09 BST
Cc: rrrs-authors@MC.lcs.mit.edu
In-Reply-To: <890705-210534-7725@Xerox>; from "Pavel.pa@xerox.com" at Jul 05, 89 9:05 pm
X-Mailer: Elm [version 2.0 beta]
Re: Fluid Binding
An effective approach to fluid binding is dynamic localisation of arbitrary
expressions, exemplified by the "dlocal" construct of Pop11. The idea is to
permit the localisation of any expression & fluid binding drops out as a
special case.
The general construct might be [I'm not suggesting this syntax]..
(dlocal
(
( save-expression entry-action exit-action )
( save-expression entry-action exit-action )
...
)
body
)
and the code generated for
(let-fluid
((x E))
body
)
would expand into
(dlocal
( ( x ; save
(set! x E) ; entry
(set! x (saved)) ; exit, with the "saved" form
)
)
body ; sequence of expressions
)
It would then be possible to do things like localise the "car" of a pair.
eg.
(dlocal
( ( (car x) ; save
(set-car! x E) ; entry-action
(set-car! x (saved)); exit-action
)
)
...
)
In Pop11 there is an association between access procedures such as "car" and
the update procedure "set-car!" ; namely an operation called "updater" which
maps "car" into "set-car!". Because of that, it is possible to write dlocal
expressions more elegantly as
(dlocal
( (save-expression update-value)
...
)
body
)
So the dynamic localisation of the "car" of a list would be
(dlocal
( ((car x) E)
...
)
)
The common case of localising a variable could be done by simply allowing a
third form for that.
(dlocal
( (variable E)
...
)
...
)
Putting these cases together, here is a piece of code that localises the
variable "x", the car of the list "y", and closes the output-port "z" on exit.
(dlocal
( (x Ex)
((car y) Ey)
(nil nil (close-output-port z))
)...
)
An interesting issue is deciding how dynamic localisation interacts with
continuations. In Pop11, the default solution is to run local-actions on
continuation activation. However it is possible to determine whether the
local-action is being run because of a continuation swap or a procedure exit.
Determining the right solution for Scheme would require careful thought.
Steve Knight
∂06-Jul-89 0843 @mc.lcs.mit.edu:jinx@ZURICH.ai.mit.edu Fluid binding
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 6 Jul 89 08:43:46 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa04606;
6 Jul 89 11:42 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 6 Jul 89 11:37:54 EDT
Received: from [18.43.0.171] by mintaka.lcs.mit.edu id aa04479;
6 Jul 89 11:31 EDT
Return-Path: <jinx@ZURICH.AI.MIT.EDU>
Received: by ZURICH.AI.MIT.EDU; Thu, 6 Jul 89 11:28:47 edt
Date: Thu, 6 Jul 89 11:28:47 edt
From: "Guillermo J. Rozas" <jinx@ZURICH.ai.mit.edu>
Message-Id: <8907061528.AA01541@ZURICH.AI.MIT.EDU>
To: sfk@hplb.hpl.hp.com
Cc: Pavel.pa@xerox.com, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Steve Knight's message of Thu, 6 Jul 89 15:01:09 BST <8907061404.AA28845@otter.hpl.hp.com>
Subject: Fluid binding
Pop11s dlocal is the analogous of dynamic-wind, a utility available in
some Scheme implementations.
A "shallow bound" implementation of fluid-let can easily be built on
top of dynamic-wind by expanding
(fluid-let ((foo <value>))
<code>)
into
(let ((dummy <value>))
(dynamic-wind
(lambda ()
(let ((outside foo))
(set! foo dummy)
(set! dummy outside)))
(lambda ()
<code>)
(lambda ()
(let ((inside foo))
(set! foo dummy)
(set! dummy inside)))))
Unfortunately this does not work well on shared memory multiprocessors,
as Pavel pointed out.
∂06-Jul-89 1012 @mc.lcs.mit.edu:mkatz@sesame.stanford.edu Assignment to standard variables
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 6 Jul 89 10:12:40 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa05654;
6 Jul 89 13:04 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 6 Jul 89 12:38:24 EDT
Received: from Sesame.Stanford.EDU by mintaka.lcs.mit.edu id aa05358;
6 Jul 89 12:32 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA25682; Thu, 6 Jul 89 09:31:39 PDT
Date: Thu, 6 Jul 89 09:31:39 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8907061631.AA25682@sesame.Stanford.EDU>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Pavel.pa@xerox.com's message of Wed, 05 Jul 89 20:04:36 PDT <890705-200443-7674@Xerox>
Subject: Assignment to standard variables
Date: Wed, 05 Jul 89 20:04:36 PDT
From: Pavel.pa@xerox.com
The majority of responses recently have been to my proposal that it be an
error to assign to the standard variables, present in the so-called
``initial environment''.
Jinx's first message on this topic stated his opposition to the proposal on
the grounds that ``the user takes precedence over the system'', the meaning
of which he clarified in a subsequent message. There, he says:
... the system/implementation is a
tool for the user, and as such it should accomodate the wishes of the
user, not viceversa. Thus if a user wants to call CAR something he
writes/uses (in a Church pair implmentation, for example), he should
be allowed to do so.
I have two counterarguments to this. First, since the user cannot portably
assign to (or even rebind) variables named ``if'', ``or'', ``delay'', or
even ``unquote'' (uses of which cannot conflict with its assigned meaning),
the user has already lost this battle.
This is one of the reasons we need macros. As soon as we have them, I will be
able to override the default definitions for special forms as well.
Second, I question the whole notion of ``user''. Your usage (and that of
most of the other respondents) implies that there is some human,
interactively manipulating the state of some Scheme implementation. This
vision of Scheme implementations is not universal. In particular, it is
easy for me to imagine Scheme systems with many ``users'' and none at all.
In a large system, simultaneously running the code of many programmers,
each of those hackers is a ``user'' in the sense that you mean. For any
one of them to decide to change the value of a standard variable would very
likely be disastrous for all of the others.
I would suggest that in such an environment each of the users should have their
REP loop executing in a separate binding environment in which all of the Scheme
primitives are bound. When a user rebinds a primitive in this type of
environment structure, they only effect themselves. If you have a module
package (as I believe you want), a user who has rebound a primitive could get
back the original definition by looking it up in some (possibly immutable in
your implementation) system environment/module.
This is the value of lexical scoping. It is not necessary for that one
iconoclastic user to make an assignment to CAR; they can simply rebind that
name over the scope of their piece of code. That way, they're happy
because they can use what they see as intuitive names, and the other users
are happy because the standard variables have the predicted standard
values.
With things as they are, you cannot afford to load any code I might send
you into your running system; I might very well make every other
``user-level'' piece of code bomb completely.
(See above, not true)
The model of a single Scheme programmer sitting at his read-eval-print loop
running only his own small program cannot be the sole customer of this
language design, or else Scheme deserves the occasional claim that it is
but a ``toy'' language. If this is the goal of the bulk of the RRRS
authors, then please let me know; I'll go quietly. I sincerely hope it is
not.
Jinx also mentioned the use of declarations to allow compilers to process
uses of standard variables more efficiently. One should not have to work
in a modified language semantics in order to get reasonable efficiency. In
particular, it seems odd to resort to such semantically inconsistent
constructs just to retain the dubious right to assign to CAR.
You cloud this issue by placing your value judgements on the rebinding of
primitves by refering to our desire to do such as of "dubious" value. What we
are really discussing is what should be the default semantics. If your
semantics were the default then I would require a declaration to enable
rebinding of primitives. I happen to feel that this second polarity ios less
elegant; but, you would obviously disagree. At the risk of offending the faint
of heart, I would point out that many systems also have type declarations to
improve compilation efficiency; however, I doubt many people would state that
Scheme should always require type information be supplied in all constructs in
order to avoid anyone ever having to use such declarations.
In his second message, Jinx offered a ``pragmatic'' reason for opposing my
proposal:
Presumably you would like
implementations to be able to add new primitives to the language
described in the report. Given that the semantics of any programs
using them might be compromised in the same way that it would be when
using a "standard" primitive, you would disallow assignment and
redefinition of implementation-specific primitives as well. This
implies that portability can only be achieved by using obscure names
(ie G00034), since any "reasonable" name is potentially reserved by
some implementation.
R4RS already requires, in section 1.3.1, that every implementation provide
a ``syntactic mode that preempts no lexical conventions of this report and
reserves no identifiers'' other than those listed in the report. Such a
mode is explicitly included to ``support portable code''.
Morry Katz, in contrast, appears to be closer to supporting my proposal.
In his June 28 message on the subject, he says:
You did not request that an implementation be allowed to prohibit
redefinition of the primitives, but stated that you wanted redefinition
of a primitive to be an error.
He also says:
If you would like to propose something that allows your system to
consider redefinition an error but does not require my system
to do such, I might be willing to consider it.
When we state that a certain situation ``is an error'', we state that the
effect of achieving that situation is unspecified. In particular, if we
state that assigning to standard variables is an error, the effect in one
implementation might be that the assignment takes place without difficulty.
In another, an error might be signalled. In another, the compiler might
reject the program, noticing that the assignment expression cannot be
performed without signalling an error. The phrase ``is an error''
encompasses all of these possibilities. Thus, when I ask that we make
assignment to standard variables an error, I am, indeed, proposing
``something that allows [my] system to consider redefinition an error but
does not require [your] system to do such.'' This is the point I was
trying to make in my previous message on this topic. I was not attempting
to pervert Morry's meaning at all.
You have grossly misrepresented my position (albeit probably by accident). I
believe that anything which is described by "is an error" in the report to be a
violation of Scheme. To have the semantics which I believe are correct be
described as "is an error" is COMPLETELY unsatisfactory to me. I suggest that
we, as a community, work harder on agreeing on some module system. This would
allow us to agree on the name a module in which all of the primitives would be
bound to implementations of the semantics specified in RNRS. Users who wanted
to guarantee that the values of the primitves never changed could reference
them in this module.
Morry also mentions declarations:
Nearly everyones compiler currently allows a compiler directive to the
effect
that primitives should be considered immutable and therefore
inlineable. This
has been done for the obvious efficiency reasons and does not require
that the
language specification be altered to always prohibit modifying
primitives.
It is to me a sign of the weakness of the current specification that
``nearly everyone'' feels the need to restrict the semantics in order to
generate reasonable code.
Pavel
(see above)
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂06-Jul-89 1035 @mc.lcs.mit.edu:mkatz@sesame.stanford.edu Fluid binding
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 6 Jul 89 10:34:39 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa05813;
6 Jul 89 13:15 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 6 Jul 89 12:44:59 EDT
Received: from Sesame.Stanford.EDU by mintaka.lcs.mit.edu id aa05480;
6 Jul 89 12:41 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA25714; Thu, 6 Jul 89 09:41:08 PDT
Date: Thu, 6 Jul 89 09:41:08 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8907061641.AA25714@sesame.Stanford.EDU>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Pavel.pa@xerox.com's message of Wed, 05 Jul 89 21:05:31 PDT <890705-210534-7725@Xerox>
Subject: Fluid binding
Date: Wed, 05 Jul 89 21:05:31 PDT
From: Pavel.pa@xerox.com
In conversations with several other members of this group, it has been
mentioned that there really isn't very much disagreement any longer on the
issue of fluid binding; it is usually noted that we simply need a concrete
proposal on which to agree. On this optimistic assumption, therefore, I
offer the following.
I hope that we can agree on the following points concerning fluid binding:
-- We want some kind of facility in the language that supports a form of
dynamic binding.
-- We do not want a Common Lisp-style two-namespace solution.
-- The binding construct has a syntax something like LET, in which a set of
expressions are evaluated in an unspecified order and their values used in
establishing new fluid bindings.
-- The extent of those bindings is dynamic, in the sense that they are in
effect exactly during the evaluation of the body of the binding form.
-- As a consequence, continuations created in that body should capture the
fluid environment and re-establish it upon invocation. Such
re-establishment should not involve re-evaluating the non-body expressions
in the binding form.
-- Upon exit from the body of the binding form, the bindings in effect
before entry to the form should be restored.
One of the most commonly-cited proposals for such a facility is described,
for example, in Kent Dybvig's book. In that facility, the so-called
``binding form'' in fact creates no bindings at all. Instead, it saves the
current values of the named lexically-visible variables, assigns new values
during the evaluation of the body, and restores the old ones after the body
is finished. This could be described implementationally as ``shallow
binding lexical variables''.
There are some problems with this idea for some implementations.
In a time-shared multiprocessing implementation, on each context switch the
set of bindings for each of the old and new running process must be
re-traversed, in order to properly save the old context and re-establish
the new.
Further, if two processes share a continuation, then one would expect that
when they share the captured fluid environment they also share the
``state'' of those bindings. For example, if a process fluid-binds a
particular variable, captures the continuation, modifies the variable, and
then forks a process invoking the newly-created continuation, I would hope
that the new process would ``see'' the new value of the shared fluid
binding. Of course, the two processes should also be able to communicate
by repeated assignments to the shared binding. I do not see how to
implement this.
Matters are even worse for a multiprocessor implementation (that is,
multiple instruction single data, such as on a Sequent or other
shared-memory multiprocessor). In this case, I can see no way to avoid the
use of deep binding to get the desired semantics. In a shallow bound
implementation, multiple processes will ``race'' for ``rebinding'' a shared
variable and ultimately lose horribly.
Given that some implementations will be forced to use deep binding, we
could simply consider using the same syntax and semantics as before, but
with a deep binding implementation. In such a situation, if a particular
variable might at some point be fluid-bound, then all references (both read
and write) would have to invoke the deep binding lookup mechanism. Since
this would, of necessity, include all global variables (since a compiler
can never claim to have seen all uses of a global variable, it must assume
the worst), I conclude that the performance degradation would be
unacceptable. (There are ways to make this a little better, such as adding
a bit to each such variable to say whether or not it has ever been
fluid-bound. If not, then the value must be in the global cell and the
expensive lookup can be avoided. It still sounds too slow to me.)
The problem here is that references to fluid-bound variables cannot, in
general, be lexically distinguished from references to non-fluid-bound
variables. My proposal, therefore, makes such a distinction, in a sense.
To the best of my recolection, all of these problems were adequately addressed
in a solution to this problem of fluid-let for multiprocessors deveoloped at a
meeting between the MIT CScheme community and the BBN Butterfly Scheme group
about 3 years ago. Again straining my memory, I seem to recall that most of
the good ideas came from Chris Hansen, so we should probably ask him to refresh
our collective memories as to his solution.
Having motivated the design, I now present it.
=========
(MAKE-FLUID obj) [Procedure]
Create and return a new ``fluid variable'' whose global value is obj.
(FLUID-REF fluid-variable) [Procedure]
Return the value of the given fluid-variable in the current fluid
environment.
(FLUID-SET! fluid-variable obj) [Procedure]
Change the value of the given fluid-variable in the current fluid
environment. The returned value is unspecified.
(FLUID-LET ((var-expr val-expr) ...) body) [Syntax]
Evaluate the var-exprs and val-exprs in an unspecified order; the var-exprs
should yield fluid variables. Return the value of the body in a new,
nested fluid environment in which the given fluid variables have new
bindings, initialized to the given values. This fluid environment has
precisely the same extent as the evaluation of the body and is thus
captured by continuations created within the body and re-established by
those continuations on invocation.
=========
The implementation is free to adopt either shallow or deep binding. In
either case, a ``fluid variable'' is simply a one-cell allocated datum
containing the value of the fluid variable either in the current fluid
environment (shallow binding) or in the global, top-level fluid environment
(deep binding). In either case, the address of the cell can be used as the
``identifier'' for the variable in the environment. This proposal, in
comparison to the one discussed before, increases the cost per reference in
a shallow-bound implementation by one memory reference, indirecting through
the cell-address. This seems a small price to pay.
The proposal is unusual in that the variable position in FLUID-LET is
evaluated, but I anticipate that in almost all uses the expression will be
a simple lexical variable reference:
(define *foo* (make-fluid 7))
(fluid-let ((*foo* 8))
(+ (fluid-ref *foo*) 1))
=> 9
Comments?
Pavel
I find this special designation of fluid variables to be quite distasteful. It
would require a much better argument as to the impossibility of doing shallow
binding reasonably on multiprocessors before I would be willing to accept a
proposal of this form.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂06-Jul-89 1043 @mc.lcs.mit.edu:mkatz@sesame.stanford.edu Fluid binding
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 6 Jul 89 10:43:46 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa06108;
6 Jul 89 13:36 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 6 Jul 89 13:27:30 EDT
Received: from Sesame.Stanford.EDU by mintaka.lcs.mit.edu id aa05953;
6 Jul 89 13:21 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA25816; Thu, 6 Jul 89 10:07:31 PDT
Date: Thu, 6 Jul 89 10:07:31 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8907061707.AA25816@sesame.Stanford.EDU>
To: sfk@hplb.hpl.hp.com
Cc: Pavel.pa@xerox.com, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Steve Knight's message of Thu, 6 Jul 89 15:01:09 BST <8907061404.AA28845@otter.hpl.hp.com>
Subject: Fluid binding
From: Steve Knight <sfk@hplb.hpl.hp.com>
Date: Thu, 6 Jul 89 15:01:09 BST
X-Mailer: Elm [version 2.0 beta]
Re: Fluid Binding
An effective approach to fluid binding is dynamic localisation of arbitrary
expressions, exemplified by the "dlocal" construct of Pop11. The idea is to
permit the localisation of any expression & fluid binding drops out as a
special case.
The general construct might be [I'm not suggesting this syntax]..
(dlocal
(
( save-expression entry-action exit-action )
( save-expression entry-action exit-action )
...
)
body
)
and the code generated for
(let-fluid
((x E))
body
)
would expand into
(dlocal
( ( x ; save
(set! x E) ; entry
(set! x (saved)) ; exit, with the "saved" form
)
)
body ; sequence of expressions
)
It would then be possible to do things like localise the "car" of a pair.
eg.
(dlocal
( ( (car x) ; save
(set-car! x E) ; entry-action
(set-car! x (saved)); exit-action
)
)
...
)
In Pop11 there is an association between access procedures such as "car" and
the update procedure "set-car!" ; namely an operation called "updater" which
maps "car" into "set-car!". Because of that, it is possible to write dlocal
expressions more elegantly as
(dlocal
( (save-expression update-value)
...
)
body
)
So the dynamic localisation of the "car" of a list would be
(dlocal
( ((car x) E)
...
)
)
The common case of localising a variable could be done by simply allowing a
third form for that.
(dlocal
( (variable E)
...
)
...
)
Putting these cases together, here is a piece of code that localises the
variable "x", the car of the list "y", and closes the output-port "z" on exit.
(dlocal
( (x Ex)
((car y) Ey)
(nil nil (close-output-port z))
)...
)
An interesting issue is deciding how dynamic localisation interacts with
continuations. In Pop11, the default solution is to run local-actions on
continuation activation. However it is possible to determine whether the
local-action is being run because of a continuation swap or a procedure exit.
Determining the right solution for Scheme would require careful thought.
Steve Knight
MIT Cscheme already has a form which is in many ways similar to DLOCAL. Its
syntax is (dynamic-wind <entry-form> <body> <exit-form>). (I hope I have those
in the correct order!) In the absence of continuations, the entry form is
executed first, followed by the body, followeed by the exit form. The value
returned by dynamic-wind is the value of BODY. If a throw to a continuation
which was captured outside the dynamic scope of a dynamic-wind form takes place
from inside the body of that form, then the exit-form of that dynamic-wind is
executed prior to invoking the continuation. Similarly, if a throw from
outside the dynamic scope of a dynamic-wind form to a continuation captured
while executing body takes place then the entry-form of the given dynamic wind
is reexecuted before the continuation is invoked. As with dlocal, fluid-let
can be built as a macro on top of this verrsion of dynamic-wind.
I do not remember if the semantics of throing into or out of the entry and exit
forms is specified for dynamic-wind. At the moment it is not obvious to me
what the correct semantics are; but, I am interested in anyones suggestions.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂06-Jul-89 1058 @MC.lcs.mit.edu:jinx@ZURICH.ai.mit.edu Fluid binding
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 6 Jul 89 10:58:10 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa06245;
6 Jul 89 13:47 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 6 Jul 89 13:38:14 EDT
Received: from [18.43.0.171] by mintaka.lcs.mit.edu id aa06027;
6 Jul 89 13:32 EDT
Return-Path: <jinx@ZURICH.AI.MIT.EDU>
Received: by ZURICH.AI.MIT.EDU; Thu, 6 Jul 89 13:29:39 edt
Date: Thu, 6 Jul 89 13:29:39 edt
From: "Guillermo J. Rozas" <jinx@ZURICH.ai.mit.edu>
Message-Id: <8907061729.AA02296@ZURICH.AI.MIT.EDU>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@MC.lcs.mit.edu
In-Reply-To: Pavel.pa@xerox.com's message of Wed, 05 Jul 89 21:05:31 PDT <890705-210534-7725@Xerox>
Subject: Fluid binding
I like your proposal, but I have a some suggestions:
1) MAKE-FLUID, FLUID-REF and FLUID-SET! don't have much to do with
fluids, they have to do with cells (or boxes, as some other people
call them). As such, I would like them to be renamed to
MAKE-CELL, CELL-REF, and CELL-SET!.
Alternatively we could have both MAKE-CELL, CELL-REF, CELL-SET! to
manipulate cells (the selector and mutator always provide the global
value), and FLUID-CELL-REF, FLUID-CELL-SET! to access the current
dynamic value. Which of the accessors is written on top of which
depends on whether the implementation is deep or shallow.
2) Although I admit that FLUID-LET would be the most common way of
obtaining dynamic behavior, I'd rather have it be a simple macro that
expands into a standard procedure. In particular, I would like to
have
(FLUID-LET ((<var-expr1> <val-expr1>) (<var-expr2> <val-expr2>) ... ) <body>)
expand into something like
(with-cell-contents
(list var-expr1 var-expr2 ...)
(list val-expr1 val-expr2 ...)
(lambda ()
<body>))
3) There are many incompatible versions of FLUID-LET out there, so I
think we should use a different name for it so that existing
implementations can continue using their code without having to
rewrite it and can provide two different mechanisms, the standard, and
the old one. I would suggest WITH-FLUID-CONTENTS or something like
that, but I'm not good at choosing names.
4)
Given that some implementations will be forced to use deep binding, we
could simply consider using the same syntax and semantics as before, but
with a deep binding implementation. In such a situation, if a particular
variable might at some point be fluid-bound, then all references (both read
and write) would have to invoke the deep binding lookup mechanism. Since
this would, of necessity, include all global variables (since a compiler
can never claim to have seen all uses of a global variable, it must assume
the worst), I conclude that the performance degradation would be
unacceptable. (There are ways to make this a little better, such as adding
a bit to each such variable to say whether or not it has ever been
fluid-bound. If not, then the value must be in the global cell and the
expensive lookup can be avoided. It still sounds too slow to me.)
It is not necessarily as expensive as you think. Assuming that
implementations have a reasonably cheap way of detecting unbound
variables at run time (perhaps the bit that you mention), you can make
all variables which have fluid values appear to be unbound, and make
the unbound trap handler "discover" that the variable was in fact
bound and fluid. Under these conditions, the cost of accessing a
global variable that has NOT been fluidized does not change, while
accessing one that has becomes a little more expensive, but not too
much if the trap mechanism is reasonably efficient.
I'm not advocating going to this method (it is what Jim Miller's
MultiScheme does), but I think that your objections on the grounds of
performance are not really justified.
∂06-Jul-89 1637 @mc.lcs.mit.edu,@ZURICH.ai.mit.edu:ramsdell@linus.mitre.org An International Character Set for R4RS
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 6 Jul 89 16:37:32 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa10625;
6 Jul 89 19:29 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 6 Jul 89 19:25:20 EDT
Received: from ZURICH.AI.MIT.EDU by mintaka.lcs.mit.edu id aa10560;
6 Jul 89 19:23 EDT
Received: from mbunix.mitre.org ([129.83.20.100]) by ZURICH.AI.MIT.EDU; Thu, 6 Jul 89 19:20:17 edt
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA21801; Thu, 6 Jul 89 13:54:17 EDT
Posted-Date: Thu, 6 Jul 89 13:54:23 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA08610; Thu, 6 Jul 89 13:54:23 EDT
Date: Thu, 6 Jul 89 13:54:23 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8907061754.AA08610@huxley.mitre.org>
To: rrrs-authors@ZURICH.ai.mit.edu
Subject: An International Character Set for R4RS
Reply-To: ramsdell@mitre.org
One way of making Scheme more inviting to Europeans, is to allow the
use of indentifiers which include letters from their alphabet. I
would like a sentences added to R4RS which encourages the support of
the ISO Latin-1 character set. Of course, no implementation would be
required to support all of the ISO Latin-1 character set.
John
∂06-Jul-89 1902 @mc.lcs.mit.edu:Pavel.pa@xerox.com Re: Assignment to standard variables
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 6 Jul 89 19:02:19 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa12449;
6 Jul 89 21:55 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 6 Jul 89 21:52:57 EDT
Received: from Xerox.COM by mintaka.lcs.mit.edu id aa12246; 6 Jul 89 21:42 EDT
Received: from Salvador.ms by ArpaGateway.ms ; 06 JUL 89 18:41:51 PDT
Date: Thu, 06 Jul 89 18:42:56 PDT
From: Pavel.pa@xerox.com
Subject: Re: Assignment to standard variables
To: rrrs-authors@mc.lcs.mit.edu
Message-ID: <890706-184151-9881@Xerox>
I'm too tired to keep fighting about (I mean, discussing) this issue. I
withdraw the proposal.
Pavel
∂06-Jul-89 2228 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #154
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 6 Jul 89 22:28:36 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa17259;
7 Jul 89 1:12 EDT
Date: 7 JUL 89 00:09:39 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #154
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID: <8907070112.aa17259@mintaka.lcs.mit.edu>
Scheme Digest #154 7 JUL 89 00:09:39 EDT
Today's Topics:
Scheme Digest #151
Looking for MIT C-scheme manual
----------------------------------------------------------------------
Date: 3 JUL 89 00:09:16 EDT
From: Automatic Scheme Digestifier <daitc!mc.lcs.mit.edu!Scheme-Request@dsac.dla.mil>
Subject: Scheme Digest #151
Reply-To: daitc!mc.lcs.mit.edu!Scheme@dsac.dla.mil
Message-Id: <8907030101.aa21379@mintaka.lcs.mit.edu>
Scheme Digest #151 3 JUL 89 00:09:16 EDT
Today's Topics:
OOP in Scheme
----------------------------------------------------------------------
Date: 2 Jul 89 07:31:07 GMT
From: Brian of ASTD-CP <brian@jade.berkeley.edu>
Subject: OOP in Scheme
Message-Id: <1404@jato.Jpl.Nasa.Gov>
; methods2.scm
;
; ===============================================================
; Brian Beckman | brian@topaz.jpl.nasa.gov
; Mail Stop 510-202 | (818) 397-9207
; Jet Propulsion Laboratory |
; Pasadena, CA 91109 | 30 June 1989
; ===============================================================
; INTRODUCTION
;
; This is a tiny object-oriented programming system with multiple
; inheritance and error handling. It is modeled after the message
; passing modules in Chapter 3 of Abelson & Sussman. It is
; implemented in ``pure'' Scheme, without macros or syntax
; extensions.
;
; This programming system is implemented as a technique, or
; programming convention, with some helper routines. The programming
; convention is not enforced, as we choose to avoid syntax-extensions
; for portability's sake. The technique is illustrated in this file
; with a few examples. In example one, a parent class, named
; ``parent,'' passes its attributes to a child named ``child.'' In
; example two, two parents, ``mother'' ``fater'', pass their attributes
; to a child class, ``daughter.'' The reader will perceive the technique
; by generalization from these examples and will be able to apply it
; to his or her own problems.
;
; Every class is represented by its constructor procedure. This
; procedure returns a message dispatching procedure. The message
; dispatching procedure should be named ``self'' so that an object can
; conveniently send messages to itself. However, ``self'' is an
; internal name not known outside the constructor.
;
; In summary, classes are represented by constructor procedures, and
; objects, or instances of classes, are represented by message
; dispatching procedures. The present version of ``methods'' does not
; support code sharing, so every instance of a class has its own
; private copies of the method code. We expect to implement code
; sharing in a later version of ``methods''.
;
; The message dispatching procedure walks the multiple inheritance
; hierarchy upwards until it finds an object that can understand a
; message, starting with itself. If no object that can understand the
; message is found, a global error procedure is called.
;
; IMPLEMENTATION
;
; Error processing is challenging. We should like to have two modes.
; In ``normal mode'', an error is reported only by the first receiver
; of a message. In ``debug mode'', an inheritance traceback should be
; given whereby every object in an inheritance hierarchy will report
; when it fails to recognize a given message. The following variable
; represents that mode. (For simplicity, this object is hidden only
; by its name, which is unusual enough that it is unlikely to be
; trammeled by an application. This is not the recommended technique
; for data hiding. Data hiding ought to be implemented through the
; techniques shown in this file! However, since this error handling
; part of the methods package is considered system programming,
; certain liberties in style are justifiable. There are in fact, good
; technical reasons for the error handling code to be implemented with
; global variables, which the perceptive reader will be able to
; deduce.)
(define **method-mode** 'normal-method-mode)
; The user can set these modes as follows.
(define (set-debug-method-mode)
(set! **method-mode** 'debug-method-mode))
(define (set-normal-method-mode)
(set! **method-mode** 'normal-method-mode))
(define (reset-debug-method-mode) ;;; synonym
(set! **method-mode** 'normal-method-mode))
; and test them with the following routine:
(define (test-debug-method-mode)
(eq? **method-mode** 'debug-method-mode))
; Before presenting the examples of classes and objects, some helper
; routines are needed.
;
; When an object cannot recognize a message, and none of its ancestor
; objects can recognize it, the object creates an error procedure and
; returns it as the result of the message dispatcher.
(define **method-error-class-name** "No class name.")
(define **method-error-message** 'no-message)
(define (error-method . junk-args)
(display **method-error-class-name**)
(display ": uknown message: '")
(display **method-error-message**)
(newline)
())
(define (make-error-method class-name msg)
(set! **method-error-class-name** class-name)
(set! **method-error-message** msg)
error-method)
; The procedure that walks the inheritance hierarchy must cooperate
; in the error handling.
(define (search-supertypes supers msg)
(define method ())
(if (test-debug-method-mode)
(begin
(display "Searching...")
(newline)))
(cond
( (null? supers) () )
( (begin
(set! method ((car supers) msg))
(eq? method error-method))
(if (test-debug-method-mode)
(error-method))
(search-supertypes (cdr supers) msg) )
( else method )))
; This procedure implements the inheritance of methods. It is greatly
; complicated by proper error handling. Without error handling, the
; routine would resemble the following, which is much easier to
; understand (without error handling, the programming convention is
; that an object that does not understand a message returns the
; unexecutable method ``()'').
;
; (define (search-supertypes supers msg)
; (cond
; ( (null? supers) () )
; ( ((car supers) msg) )
; ( else (search-supertypes (cdr supers) msg) )))
;
; The actual routine, with proper error handling, works as follows. A
; local variable, ``method'', is defined. Its value is not important
; to begin with. If debugging is on, we print a message telling the
; user that the inheritance hierarchy is being searched. Then, the
; list of supertypes is investigated. If the list is empty, we return
; nil, which signals the caller to create and return the error-method,
; as we shall see in the examples later. If the list is not empty, we
; pass the message to the first supertype in the list. The return
; value is assigned to the local variable ``method''. If the returned
; method is the one and only global error-method, then the supertype,
; and, recursively, all its supertypes, did not know the message.
; If debugging is on, we execute the returned error-method, contributing
; to the aforementioned inheritance traceback. Finally, we return
; the value of a recursive call of search-supertypes on the remainder
; of the list of supertypes. If the returned method is not the
; error-method, then the supertype did understand the message after
; all somewhere in the hierarchy, and the returned method is the
; return value of this procedure.
;
; Note that the list of supertypes is searched in order from front
; to back. The first match of a message results in the successful
; finding of a method. The order of supertypes in the list is
; significant only when more than one supertype can understand
; a given message. The earlier members of the list will shadow
; the later ones. In some object-oriented programming systems, one
; refers to the ``overriding'' of methods. The shadowing in
; ``methods'' is our form of method overriding, and it is under
; explicit control of the programmer who sets the order of supertypes
; in the list of supertypes.
;
; In summary, search-supertypes passes the message to the ancestors,
; in pre-order, returning the first method found.
;
; The next helper routine passes a message, and a variable number of
; arguments, to all the parents of an object. For side effects, it
; executes any methods found. Parents are defined as
; first level ancestors.
(define (for-all-parents supers msg . args)
(let ( (method-list
(map (lambda (supertype) (supertype msg)) supers))
(for-proc
(lambda (method) (apply method args))) )
(for-each for-proc method-list)))
; With the current programming convention, it is not possible to pass
; a message to all ancestors and execute the methods for side-effect
; without explicit cooperation on the part of the objects involved. In
; other words, the procedure ``for-all-ancestors'', analogous to
; ``for-all-parents'', cannot be implemented in the current version of
; the methods package. The reason is that the convention calls for
; every class to call ``search-supertypes'', which stops when it finds
; a method. The convention would have to be augmented so that objects
; would call ``find-all-methods'' (defined below) on an appropriate
; message. Since we expect the need for ``for-all-ancestors'' to be
; fairly rare, the necessary changes to the methods package will be
; reserved for a future version.
(define (find-all-methods supers msg)
(cond
( (null? supers) () )
( else (cons ((car supers) msg)
(find-all-methods (cdr supers) msg)) )))
; EXAMPLES (cut here to end of file to throw examples away)
;
; Our first example class, or object type, is ``parent'', represented
; by the following constructor procedure.
(define (new-parent arg)
(let ((state-var (* arg arg))
(supers ()))
(define (report-state-var)
(display state-var)
(newline)
state-var)
(define (update-state-var arg)
(set! state-var (* arg arg)))
(define (echo arg)
(display arg) (newline))
(define (self msg)
(cond
( (eq? msg 'report) report-state-var )
( (eq? msg 'update) update-state-var )
( (eq? msg 'echo) echo )
( (search-supertypes supers msg) )
( else (make-error-method "Parent" msg) )))
self))
; This class, or constructor procedure, completely illustrates, by
; example, the programming convention of the ``methods'' technique.
; The constructor takes a single argument, whose square it stores in a
; local state variable. Another state variable, the list of
; supertypes, is set to nil, since this class is at the root of an
; inheritance hierarchy. Three methods are defined, one that reports
; and returns the current value of the state variable, one that sets
; the state variable equal to a new square, and one that merely echoes
; its argument. A method dispatching procedure, conventionally named
; ``self'', tests a given message against three symbols and returns
; the corresponding method if a match is found. If no match is found,
; the list of supertypes is searched for a match. In the case of this
; class, ``parent'', the search is purely formal, to illustrate how it
; should be done, since ``parent'' has no ancestors. However, if a
; match were found among the list of supertypes, the method would be
; returned. Note how the search relys on the fact that any non-nil
; result is treated as a successful ``cond'' clause, terminating the
; ``cond'' statement. Search-supertypes returns nil only when a match
; is not found. Finally, if no match is found locally or among the
; supertypes, an appropriate error-method is pseudo-created and
; returned.
;
; We now test this class by making an instance and passing it
; messages.
(define p (new-parent 42))
((p 'report))
((p 'update) 69)
((p 'report))
((p 'echo) (list 1 2 3))
; We test error handling:
((p 'bogus))
(set-debug-method-mode)
((p 'bogus))
(reset-debug-method-mode)
((p 'bogus) 'here 'are 'some 'junk 'arguments)
; Continuing this example, let us define a child class inheriting
; all attributes and methods of the parent. Note the attributes of
; the parent are only accessible through the parent's method
; discipline. This is a strict form of inheritance, and the default
; in C++, for example. (C++ allows the programmer to override
; ancestors' access discipline, at his own peril.)
(define (new-child arg1 arg2)
(let* ( (leg1 (* arg1 arg1))
(leg2 (* arg2 arg2))
(hypotenuse (+ leg1 leg2))
(supers (list
(new-parent hypotenuse))) )
(define (report)
(for-all-parents supers 'report)
(display "Leg1 = ") (display (sqrt leg1)) (newline)
(display "Leg2 = ") (display (sqrt leg2)) (newline)
(display "Hypo = ") (display (sqrt hypotenuse)) (newline))
(define (update-leg1 val)
(set! leg1 (* val val))
(set! hypotenuse (+ leg1 leg2)))
(define (update-leg2 val)
(set! leg2 (* val val))
(set! hypotenuse (+ leg1 leg2)))
(define (self msg)
(cond
( (eq? msg 'report) report )
( (eq? msg 'update-leg1) update-leg1 )
( (eq? msg 'update-leg2) update-leg2 )
( (search-supertypes supers msg) )
( else (make-error-method "Child" msg) )))
self))
; We now test the child type.
(define c (new-child 3 4))
((c 'report)) ;;; passes message to all parents
((c 'update-leg1) 5)
((c 'update-leg2) 12)
((c 'report))
((c 'echo) '(foo bar)) ;;; msg known only in the parent
((c 'bogus) 'baz 'rat)
(set-debug-method-mode)
((c 'bogus) 'baz 'rat)
(reset-debug-method-mode)
((c 'bogus) 'baz 'rat)
; The last example, presented without detailed narrative, shows a
; slightly deeper inheritance hierarchy. The leaf is a type named
; ``daughter''. Its two parent classes are ``mother'' and ``father''.
; In turn, every mother has an ``estate'' and a ``religion'' (please
; excuse the somewhat strained metaphor of inheritance; this is just
; a little example).
(define (new-estate value)
(let ((value value)
(supers ()))
(define (report)
(display "Estate = $") (display value) (newline))
(define (what-value) value)
(define (increase amount) (set! value (+ value amount)))
(define (decrease amount) (set! value (- value amount)))
(define (self msg)
(cond
( (eq? msg 'report) report )
( (eq? msg 'what-estate) what-value )
( (eq? msg 'increase) increase )
( (eq? msg 'decrease) decrease )
( (search-supertypes supers msg) )
( else (make-error-method "Estate" msg) )))
self))
(define (new-religion theReligion)
(let ((religion theReligion)
(supers ()))
(define (report) (display "Religion = ") (display religion) (newline))
(define (what-religion) religion)
(define (convert theNewReligion) (set! religion theNewReligion))
(define (self msg)
(cond
( (eq? msg 'report) report )
( (eq? msg 'convert) convert )
( (eq? msg 'what-religion) what-religion )
( (search-supertypes supers msg) )
( else (make-error-method "Religion" msg) )))
self))
(define (new-father eye-color)
(let ((eye-color eye-color)
(supers ()))
(define (report) (display "Father's eye color = ")
(display eye-color) (newline))
(define (what-eye-color) eye-color)
(define (self msg)
(cond
( (eq? msg 'report) report )
( (eq? msg 'what-eye-color) what-eye-color )
( (search-supertypes supers msg) )
( else (make-error-method "Father" msg) )))
self))
(define (new-mother eye-color estate religion)
(let ((eye-color eye-color)
(supers (list
(new-estate estate)
(new-religion religion))))
(define (report)
(for-all-parents supers 'report)
(display "Mother's eye color = ")
(display eye-color) (newline))
(define (what-eye-color) eye-color)
(define (self msg)
(cond
( (eq? msg 'report) report )
( (eq? msg 'what-eye-color) what-eye-color )
( (search-supertypes supers msg) )
( else (make-error-method "Mother" msg) )))
self))
(define (new-daughter eye-color)
(let* ((eye-color eye-color)
(parents-eye-color
(if (eq? eye-color 'blue) 'blue 'brown))
(supers (list
(new-father parents-eye-color)
(new-mother parents-eye-color 500000 'Jewish))))
(define (report)
(for-all-parents supers 'report)
(display "Daughter's eye color = ")
(display eye-color)
(newline))
(define (what-eye-color) eye-color)
(define (self msg)
(cond
( (eq? msg 'report) report )
( (eq? msg 'what-eye-color) what-eye-color )
( (search-supertypes supers msg) )
( else (make-error-method "Daughter" msg) )))
self))
(define dbl (new-daughter 'blue))
((dbl 'report))
((dbl 'convert) 'muslim)
((dbl 'report))
((dbl 'increase) 50000)
((dbl 'report))
(define dbr (new-daughter 'brown))
((dbr 'report))
((dbr 'decrease) 250000)
((dbr 'report))
((dbr 'bogus))
(set-debug-method-mode)
((dbr 'bogus))
(reset-debug-method-mode)
------------------------------
End of Scheme Digest
********************
------------------------------
Date: 6 Jul 89 21:33:25 GMT
From: Brian of ASTD-CP <brian@topaz.rutgers.edu>
Subject: Looking for MIT C-scheme manual
Message-Id: <1415@jato.Jpl.Nasa.Gov>
We here in the Computer Graphics Lab have MIT cscheme running
and we have the R3RS to look at. But cscheme has a tremendous
number of features, extensions, and goodies that we haven't
figured out. Is there a reference manual? A user's manual?
If someone has it, would s/he be so kind as to e-mail (or even
US snail) it to us? We're limping along with MacScheme and
various installations of Betz's Xscheme, which, while very nice
indeed, doesn't seem to have the power, backing, (nor size) of
cscheme by an order of magnitude or so.
;================================================================
;| Brian Beckman | brian@topaz.jpl.nasa.gov |
;| Computer Graphics Laboratory | (818) 397-9207 |
;| Mail Stop 510-202 | (818) 397-9344 |
;| Jet Propulsion Laboratory | |
;| Pasadena, CA 91109 | 6 July 1989 |
;================================================================
------------------------------
End of Scheme Digest
********************
∂07-Jul-89 1700 @mc.lcs.mit.edu:Pavel.pa@xerox.com Re: Reserving a character for experimentation
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 7 Jul 89 17:00:31 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa08503;
7 Jul 89 19:54 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 7 Jul 89 19:51:08 EDT
Received: from Xerox.COM by mintaka.lcs.mit.edu id aa08273; 7 Jul 89 19:36 EDT
Received: from Salvador.ms by ArpaGateway.ms ; 07 JUL 89 16:29:22 PDT
Date: Fri, 07 Jul 89 16:31:25 PDT
From: Pavel.pa@xerox.com
Subject: Re: Reserving a character for experimentation
In-reply-to: <8907061359.AA00613@peanut.DEC.COM>
To: rrrs-authors@mc.lcs.mit.edu
Reply-To: Pavel.pa@xerox.com
Message-ID: <890707-162922-12108@Xerox>
It is indeed the case that, were we to agree to remove colon from the list
of allowed characters in identifiers, some now portable code would become
unportable. This is not a new concept. For example, we recently agreed to
de-specify the truth value of the empty list; a far, far more subtle way to
break previously portable code.
The argument must be that there is no consensus for making this particular
incompatible change to the language; that is, as a group, we must not
believe that the benefits of making colon available for experiementation
outweigh the costs of rendering some code unportable.
I do not agree with this view, obviously, but I value the consensus model
of decision. Thus, absent any signs of support other than from Alan
(thanks), I will withdraw yet another proposal. In so doing, though, I
would like to make two requests to the authors as a group:
1 -- Please don't change the language to allow ``#'' in identifiers; it has
been hard enough to find an acceptable character this once and I'd rather
not have to go through it again.
2 -- Over the past few weeks, I have watched no fewer than seven ideas
proposed to this mailing list. By my count, that number exceeds the number
of people stating opinions on those ideas. It is very difficult to attempt
to achieve a consensus among a large group if the vast majority are silent.
What are we to assume about those who say nothing? That they approve of
what is being said? By whom? That, perhaps, they care nothing about the
ideas being discussed and thus have no interest in how they are resolved?
I hope not.
In a recent message, Jinx noted the following:
``I'm afraid we are going to disagree very strongly on this issue, and
therefore we are at an impasse. Unfortunately that seems to be happening
with everything else that anyone proposes, so I'm afraid that R3.95RS is
the end of the line. What a pity.''
A pity indeed, if it means that Scheme will not evolve into a usable
standard language. If we ever hope for wider use of this language, we must
work harder to resolve differences and, critically, MOVE FORWARD. That
requires work, attention, and above all, participation.
End of sermon/supplication.
Pavel
∂07-Jul-89 1740 @mc.lcs.mit.edu,@ti.com:bartley@m2.csc.ti.com Responses to a month of mail
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 7 Jul 89 17:40:28 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa09099;
7 Jul 89 20:36 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 7 Jul 89 20:33:16 EDT
Received: from TI.COM by mintaka.lcs.mit.edu id aa09044; 7 Jul 89 20:30 EDT
Received: by ti.com id AA28102; Fri, 7 Jul 89 19:30:51 CDT
Received: from m2.csc.ti.com.UUCP by tilde id AA29680; Fri, 7 Jul 89 14:45:28 CDT
Received: by m2.csc.ti.com.UUCP (5.52/4.7)
id AA11314; Fri, 7 Jul 89 14:45:25 CDT
Date: Fri, 7 Jul 89 14:45:25 CDT
From: David Bartley <bartley@m2.csc.ti.com>
Message-Id: <8907071945.AA11314@m2.csc.ti.com.UUCP>
To: JMiller%crl.dec@decwrl.dec.com
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: jmiller@crl.dec.com's message of Wed, 5 Jul 89 16:53:13 EDT <8907052053.AA00249@peanut.DEC.COM>
Subject: Responses to a month of mail
Reply-To: Bartley@ti-csl.csc.ti.com
>From: jmiller@crl.dec.com
>
>I'd like to suggest that Pavel use "|" instead of ":" for his module
>separator. It's currently illegal, and I believe that his argument
>against its use (other dialects use it for an escape character) is
>very weak. It also looks pretty good for just this purpose:
>
>(module|submodule|procedure random-thing)
>
>--Jim
At least four of our implementations of Scheme use "|" the same way
Common Lisp uses it: to make funny characters seem alphabetic in
symbol names. I would also expect this to be true of other Scheme's
out there that are piggy-backed on top of other Lisps. This could
work against Pavel's module mechanism spreading to those systems.
On the other hand, I kind of like the looks of your example. Suppose
we used paired "||" instead? It seems to me that there would be no
conflict between the two uses of "|" (except perhaps readability).
(module||submodule||procedure random-thing)
--db--
∂08-Jul-89 1717 @mc.lcs.mit.edu,@sonoma.stanford.edu:shap@annabel.stanford.edu Fluid binding
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 8 Jul 89 17:17:28 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa03309;
8 Jul 89 20:12 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 8 Jul 89 19:11:24 EDT
Received: from sonoma.Stanford.EDU by mintaka.lcs.mit.edu id aa02588;
8 Jul 89 19:09 EDT
Received: by sonoma.Stanford.EDU (5.57/Ultrix2.4-C)
id AA00432; Sat, 8 Jul 89 16:09:33 PDT
Message-Id: <8907082309.AA00432@sonoma.Stanford.EDU>
Received: from annabel.STANFORD.EDU by dolores; Sat, 8 Jul 89 16:10:19 pdt
Received: by sid; Sat, 8 Jul 89 14:03:02 pdt
Date: Sat, 8 Jul 89 14:03:02 pdt
From: "Jonathan S. Shapiro" <shap@annabel.stanford.edu>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Pavel.pa@xerox.com's message of Wed, 05 Jul 89 21:05:31 PDT <890705-210534-7725@Xerox>
Subject: Fluid binding
Several comments:
This is syntactically gross. The presence of FLUID-REF in effect
separates things into two namespaces, which is awful. I also don't
like the fact that FLUID-LET evaluates its variables.
People may not like it, but I think this wouldbe better handled as
follows:
(DEFINE FRED)
(DECLARE FRED 'fluid)
LET continues to work as you expect, but when applied to a fluid
variable does a fluid-let. Within the context of such a fluid-let, as
set! behaves in the way one expects.
I fail to see why we need any additional syntax to accomplish this.
Perhaps someone can enlighten me.
∂08-Jul-89 1732 @mc.lcs.mit.edu,@sonoma.stanford.edu:shap@annabel.stanford.edu Assignment to standard variables
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 8 Jul 89 17:32:14 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa03421;
8 Jul 89 20:20 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 8 Jul 89 19:11:32 EDT
Received: from sonoma.Stanford.EDU by mintaka.lcs.mit.edu id aa02590;
8 Jul 89 19:09 EDT
Received: by sonoma.Stanford.EDU (5.57/Ultrix2.4-C)
id AA00436; Sat, 8 Jul 89 16:09:35 PDT
Message-Id: <8907082309.AA00436@sonoma.Stanford.EDU>
Received: from annabel.STANFORD.EDU by dolores; Sat, 8 Jul 89 16:10:23 pdt
Received: by sid; Sat, 8 Jul 89 13:56:43 pdt
Date: Sat, 8 Jul 89 13:56:43 pdt
From: "Jonathan S. Shapiro" <shap@annabel.stanford.edu>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Pavel.pa@xerox.com's message of Wed, 05 Jul 89 20:04:36 PDT <890705-200443-7674@Xerox>
Subject: Assignment to standard variables
I think pavel has missed several points.
Regarding being unable to rebind `if', `or', `delay', etc. There is a
distinction to be made between symbols that are syntax and symbols
that are functions. One of the beauties of scheme is that the set of
identifiers that is reserved is very small. It is also unlikely to
change very much. This makes the syntactic keywords rather different
from the standard functions that are part of the environment. There
is less risk of incompatible extension, and there are strong
experiential arguments (e.g. Algol) for not having syntactic keywords
be assignable. Indeed, making things like IF assignable would
introduce a fundamental ambiguity into the language.
Lexical scoping is insufficient to get around this problem, partly
because of the define semantics issue. It is not the case that I can
take a randomchunk of code and stick it inside a LETREC somewhere and
have things remain consistent. In particular, the following two code
fragments are not identical. One is an error:
(DEFINE foo 3) (let ()
(SET! foo 4) (DEFINE foo 3)
(DEFINE bar 5) (SET! foo 4)
(DEFINE bar 5))
What is needed here is environments, and the only thing that we all
seem to be able to agree on with regard to environments is that we
disagree strongly on what they should be like.
The requirement of a clean syntactic mode doesn't get you out of the
incompatibility problem, unless I have misunderstood the intent of
R3.95RS in this regard. The clean environment prohibits extensions to
the standard-described language, yes. It doesn't, however, prohibit
changes to the standad. In R5RS the standard might change in a way
that breaks existing programs if we adopt your proposal. This should
be avoided if possible.
I also believe that your interpretation of "it is an error" is wrong.
When we state that behavior is unspecified, we mean that it is is
unspecified. When we state that something is an error, we mean that
it is a wrong thing to do, not that it is unspecified. The fact that
implementations are permitted to be lazy is not a good rationale for
destroying the meaning of "it is an error."
Frankly, I think that the idea of creating a DECLARE form makes the
most sense of all. It would let the decision of immutability be left
with the programmer without compromising any of Pavel's objectives.
In one regard, however, I agree with Pavel. The transformation that
was proposed for environments is sufficiently verbose that it is a
pain in the ass to use, and I agree with him that it is undesirable.
I also agree that the right character to use, if any, is `:', for the
reasons he stated.
Jon
∂08-Jul-89 1751 @mc.lcs.mit.edu,@sonoma.stanford.edu:shap@annabel.stanford.edu Reserving a character for experimentation
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 8 Jul 89 17:51:16 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa03548;
8 Jul 89 20:30 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 8 Jul 89 19:22:31 EDT
Received: from sonoma.Stanford.EDU by mintaka.lcs.mit.edu id aa02611;
8 Jul 89 19:11 EDT
Received: by sonoma.Stanford.EDU (5.57/Ultrix2.4-C)
id AA00428; Sat, 8 Jul 89 16:09:28 PDT
Message-Id: <8907082309.AA00428@sonoma.Stanford.EDU>
Received: from annabel.STANFORD.EDU by dolores; Sat, 8 Jul 89 16:10:16 pdt
Received: by sid; Sat, 8 Jul 89 14:07:15 pdt
Date: Sat, 8 Jul 89 14:07:15 pdt
From: "Jonathan S. Shapiro" <shap@annabel.stanford.edu>
To: JMiller@crl.enet.dec.com
Cc: Pavel.pa@xerox.com, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: jmiller@crl.dec.com's message of Thu, 6 Jul 89 09:59:48 EDT <8907061359.AA00613@peanut.DEC.COM>
Subject: Reserving a character for experimentation
> Perhaps what you meant is that no individual's code running
> in an existing implementation would be affected -- but I'm more
> worried about the portable code I've written over the years. I'd like
> it to remain portable, and your suggesting one more headache to worry
> about.
I don't find this argument particularly compelling, given that the
program to transform colon-using code to non-colon-using-code is so
short.
Jon
∂08-Jul-89 2224 @mc.lcs.mit.edu:jinx@ZURICH.ai.mit.edu Fluid binding
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 8 Jul 89 22:24:08 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa06119;
9 Jul 89 1:03 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 9 Jul 89 00:55:14 EDT
Received: from [18.43.0.171] by mintaka.lcs.mit.edu id aa05972;
9 Jul 89 0:53 EDT
Return-Path: <jinx@ZURICH.AI.MIT.EDU>
Received: by ZURICH.AI.MIT.EDU; Sun, 9 Jul 89 00:50:33 edt
Date: Sun, 9 Jul 89 00:50:33 edt
From: "Guillermo J. Rozas" <jinx@ZURICH.ai.mit.edu>
Message-Id: <8907090450.AA01092@ZURICH.AI.MIT.EDU>
To: shap@annabel.stanford.edu
Cc: Pavel.pa@xerox.com, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: "Jonathan S. Shapiro"'s message of Sat, 8 Jul 89 14:03:02 pdt <8907082309.AA00432@sonoma.Stanford.EDU>
Subject: Fluid binding
This is syntactically gross. The presence of FLUID-REF in effect
separates things into two namespaces, which is awful. I also don't
like the fact that FLUID-LET evaluates its variables.
The only syntax in Pavel's proposal is FLUID-LET, the others are
procedures. His proposal does not introduce another namespace.
Instead of adding a new kind of environment or variable, he makes
fluids first class objects whose contents are context sensitive.
The name fluid is loaded, think of them as cells (pairs with only one
component).
People may not like it, but I think this wouldbe better handled as
follows:
(DEFINE FRED)
(DECLARE FRED 'fluid)
LET continues to work as you expect, but when applied to a fluid
variable does a fluid-let. Within the context of such a fluid-let, as
set! behaves in the way one expects.
This is virtually impossible to implement correctly in the presence of
separate compilation. The only way to get this to work would be to
make the assumption that all free variables are special (I mean fluid,
sorry), which is what Common Lisp does.
I fail to see why we need any additional syntax to accomplish this.
Perhaps someone can enlighten me.
Pavel's proposal does not require syntax, since FLUID-LET can be
replaced by a procedure as I suggested in a previous message. On the
other hand, FLUID-LET would be the most common way of using fluids,
and the procedures would hardly ever be used directly.
∂09-Jul-89 2121 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #155
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 9 Jul 89 21:21:42 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa01550;
10 Jul 89 0:19 EDT
Date: 10 JUL 89 00:09:37 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #155
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID: <8907100019.aa01550@mintaka.lcs.mit.edu>
Scheme Digest #155 10 JUL 89 00:09:37 EDT
Today's Topics:
Learning/teaching Scheme as a first language - Summary
----------------------------------------------------------------------
Date: 7 Jul 89 15:59:06 GMT
From: Dave McKellar <mailrus!jarvis.csri.toronto.edu!utgpu!utzoo!yunexus!intacc!mckellar@ohio-state.arpa>
Subject: Learning/teaching Scheme as a first language - Summary
Message-Id: <1989Jul7.115906.7544@intacc.uucp>
Many thanks to the 16 kind people who replied to my query about
an easy reading book on Scheme. Here is what they said...
Easy Reading Books on Scheme
============================
The Little Lisper by Daniel P. Friedman and Matthias Felleisan
----------------- of Indiana University
Programming in Scheme by Mike Eisenberg
--------------------- published by Scientific Press
The Scheme Programming Language by Kent Dybvig
------------------------------- published by Prentice Hall
Introduction to Scheme by Jerry Smith
---------------------- published by Prentice Hall
The 'World's biggest bookstore', here in Toronto, has a shelf of Lisp
books but none of these.... shocking!
--
----------
{uunet,watmath,utzoo}!mnetor!intacc!mckellar "Taste is a matter of taste."
----------
------------------------------
End of Scheme Digest
********************
∂10-Jul-89 1447 @MC.lcs.mit.edu:Alan@REAGAN.ai.mit.edu R↑3.95RS: open-input-file open-output-file
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 10 Jul 89 14:47:48 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa25367;
10 Jul 89 17:13 EDT
Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by MC.LCS.MIT.EDU 10 Jul 89 17:10:36 EDT
Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 233698; Mon 10-Jul-89 17:09:51 EDT
Date: Mon, 10 Jul 89 17:09 EDT
From: Alan Bawden <Alan@REAGAN.ai.mit.edu>
Subject: R↑3.95RS: open-input-file open-output-file
To: JMiller@crl.enet.dec.com, rrrs-authors@MC.lcs.mit.edu
In-Reply-To: <8907052107.AA00259@peanut.DEC.COM>
Message-ID: <19890710210947.5.ALAN@PIGPEN.AI.MIT.EDU>
Date: Wed, 5 Jul 89 17:07:22 EDT
From: jmiller@crl.dec.com
At the risk of opening an entire can of worms, what about passing an
optional flag in to OPEN-... specifying (if present and EQ? to #T)
that a return value of #F is valid....
The Lisp Machine system's OPEN used to do something like this. If you gave
it the right flag as an optional argument, OPEN would either return a open
stream, or an "error object" that described why the file couldn't be
opened. This style of programming turned out to be very clumsy and error
prone. Once you start returning streams and error objects from the same
function, the next step is to store them both in the same variables. Then
you've got them in the same slots in data structures. Passing an error
object to an I/O primitive as a stream becomes a common path into the
debugger. Also other functions that return streams might want to return
error objects as well, so then they need to support the same optional flag
argument.
The condition system that replaced this style of OPEN was an immeasurable
improvement.
∂10-Jul-89 2055 @mc.lcs.mit.edu,@decwrl.dec.com:jmiller@crl.dec.com LIST-REF, revisited
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 10 Jul 89 20:55:50 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa28793;
10 Jul 89 20:09 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 10 Jul 89 16:35:22 EDT
Received: from decwrl.dec.com by mintaka.lcs.mit.edu id aa23490;
10 Jul 89 16:30 EDT
Received: from crl.crl.dec.com by decwrl.dec.com (5.54.5/4.7.34)
id AA02002; Mon, 10 Jul 89 13:29:53 PDT
Received: from crl.crl.dec.com by decwrl.dec.com (5.54.5/4.7.34)
for rrrs-authors@mc.lcs.mit.edu; id AA02002; Mon, 10 Jul 89 13:29:53 PDT
Received: by crl.crl.dec.com (5.57/Ultrix2.4-C)
id AA12173; Mon, 10 Jul 89 13:44:02 EDT
Date: Mon, 10 Jul 89 13:40:41 EDT
From: jmiller@crl.dec.com
Message-Id: <8907101740.AA02171@peanut.DEC.COM>
To: rrrs-authors@mc.lcs.mit.edu
Subject: LIST-REF, revisited
Reply-To: JMiller@crl.enet.dec.com
At the recent IEEE Working Group meeting it was proposed that we again
respectfully request the Authors to consider the inclusion of the
procedure LIST-REF. The argument is fundamentally to provide parallel
constructs for strings, lists, and vectors. The Authors have already
adopted the addition of STRING to aid in this effort. It was the
consensus of the meeting that the omission of LIST-REF from the IEEE
Draft Standard was undesirable, while the omission of LIST-TAIL was
acceptable since no similar procedure exists for the other data types.
Can we reach consensus on this one procedure?
--Jim Miller
P.S. -- I (personally, as opposed to the IEEE WG meeting) urge the
Authors to carefully re-read Morry Katz's initial proposal for
regularizing the data types. Perhaps Morry can find a copy of his
earlier message, reconsider it, and resubmit it for comments. I don't
believe that it can be acted on in time for the IEEE Draft, but
certainly R5RS is an appropriate vehicle for these considerations.
∂11-Jul-89 0857 @mc.lcs.mit.edu,@ZURICH.ai.mit.edu:ramsdell@linus.mitre.org International character sets.
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 11 Jul 89 08:57:11 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa07559;
11 Jul 89 9:33 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 11 Jul 89 09:28:39 EDT
Received: from ZURICH.AI.MIT.EDU by mintaka.lcs.mit.edu id aa07464;
11 Jul 89 9:23 EDT
Received: from mbunix.mitre.org ([129.83.20.100]) by ZURICH.AI.MIT.EDU; Tue, 11 Jul 89 09:20:24 edt
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA07932; Tue, 11 Jul 89 09:19:43 EDT
Posted-Date: Tue, 11 Jul 89 09:19:37 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA00208; Tue, 11 Jul 89 09:19:37 EDT
Date: Tue, 11 Jul 89 09:19:37 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8907111319.AA00208@huxley.mitre.org>
To: rrrs-authors@ZURICH.ai.mit.edu
Subject: International character sets.
Reply-To: ramsdell@mitre.org
Here is a more specific proposal on international character sets.
Add the following sentence to the begining of paragraph -2, column 2,
page 4, which descibes when upper and lower case letters are
destinguished.
Implementations are encouraged to support at least
the ISO Latin 1 (ISO8859-1) character set.
John
PS. On the internationalization of Eiffel
From: sommar@enea.se (Erland Sommarskog)
Newsgroups: comp.lang.eiffel
Date: 8 Jul 89 20:40:27 GMT
Organization: Enea Data AB, Sweden
In one of his many interesting articles Bertrand Meyer said if one
wants changes in Eiffel the next six months is the time to ask for
them. Since I think Eiffel has to be improved with regards to supporting
human langauges other English, I will try to summarize the potential
problem areas I'm aware of. I'm not an expert in neither Eiffel nor
character-set standards, so I will not try to provide complete solutions,
but merely point out the requirements.
Before I go any further, let me add that these problems are in no
way unique to Eiffel. Since some time ISO requires support of multi-
national character sets when they are approving or revising a
language standard. The problems connected with this vary from langauge
to langauge, as do the solutions.
I first give an overview of existing character sets. I then discuss
the various problem areas: Operator and delimiter characters, literals,
identifiers and finally operations as comparisons.
!
Standardized character sets
---------------------------
There are several character-set standards, which I briefly describe
since not everyone may be well acquinted with them.
ASCII - The standard on which about everything else is based.
EBCDIC - Appears in some worlds, but none I have experience of.
ISO 646 - A seven-bit standard, where some characters in the ASCII
are replaced by national characters. Which are the replace-
ments depends on the country you're in. For instance in
Sweden left brace is replaced with dotted "a", in France
it's an "e" with accent aigue.
ISO 2022 - A standard that describe how to change between different
character sets.
ISO 6937 - A eight-bit set, which doesn't seem to have been adopted
very much. Slots 0-127 are ASCII. From 161 and up are mute
modifiers and national letters. With 6937 dotted "a" is
produced by first given a diaresis and then the "a".
Virtually all langauges with a Latin alphabet, except
Vietnamese, could be written with this set.
ISO 8859 - Nine standards which all have ASCII in 0-127 and control
characters in 128-159. Then the contents varies depends on
the geographical are addressed. Five of the sets has Latin
characters, then there's one each for Cyrillic, Hebrew, Arabic
and Greek. I don't know whether all nine has finally been
settled. Some may still be drafts.
One could expect that the absolutely most commonly supported
will be 8859/1, also known as Latin-1. Latin-1 covers most
of the languages in Western Europe. (Exlcuded are Welsh and
Catalan.)
8859 has no mute characters.
ISO 10646 - A multi-octet character set, which is under development.
I know very little of it, but I doubt there is even a
draft of it. There was a posting about it in comp.std.internat
some time ago.
In the following I will conentrate on ISO 646 and 8859. Although I
personally am appealed by the ideas in 6937, its use in real life
is small, so I'm disregarding the problems that supporting this standard
would cause.
!
Operator and delimiter characters
---------------------------------
With an eight-bit set based on ASCII there are rarely any problem.
However, in a seven-bit world there are. Any programming language using
any of the characters @[\]↑`{|}~ as an operator or a delimiter is
committing a crime in my eyes. Most of the national sets that ISO 646
defines replaces these characters with national characters, and in many
cases these characters are letters. So in my eyes a notation like
class BIN_TREE [T]
is just as bad as:
class BIN_TREE ZTQ
(Read Z and Q as opening and closing delimiters!)
Many languages that use these characters alleviates the problem
by providing alternative tokens. For instance, Ada allows you use "!"
for "|". Many Pascal compilers allow "(." and ".)" for [], and (* and
*) are more common than {}.
Eiffel is a sinner in this field. With Dr. Meyer's origin in mind,
I assume he is not unaware of the problems, but has chosen to ignore
them. Still I hope he will re-think and change his mind on this issue.
Letters as special characters is simply not a good idea.
One could argue that since we're moving into a eight-bit world,
this is a disappearing problem, but remember that that transition
is slow. We will live with seven-bits terminals and printers quite
a long time still.
Now, what actual problems do we have in Eiffel? The occurance of brackets
and braces in Eiffel is restricted to the class declaration and the export
clause which gives less pain than if they could occur anywhere. Anyway,
finding replacement characters should be easy. (To be honest I don't
really see why they had been chosen in the first place. Is there some
lexical problem that prevents simple parenthesis?)
Worse is the backslash. Could you think of having to double all "W"s
in your string literals? Probably not, so you wouldn't pick "W" as
the escape character. Eiffel has chosen the bad habit from C of using
dotted "O" (which is how the backslash appears on my screen). Here
I not only want an alternate character, but also I want to get rid
of the original. (As a whole, I am not fond of the C style of writing
character and string literals, why use octal codes?)
!
Literals
--------
Which characters can I use in string and character literals? If
we forget the fatal backslash, Eiffel doesn't give me any problem
if I'm using any of the 8859 standards. It is just to go ahead and
use them. (At least that is what its description alludes. For what
happens in real life, see an adjacent article of mine.)
Other people will get problems, though, mainly Japanse and Chinese
programmers. I.e., there is no support for multi-byte sets.
As a side note, a language which really is evil here is Ada. Ada
explictly forbids non-printing charcaters in literals, and "non-
printing" is defined from ASCII, so using the upper half of Latin-1
in Ada is a real pain. Ada-9X will resolve this, but that's another
three or four years from now. Sigh.
!
Identifiers
-----------
Eiffel, as most other langauges, allows the letters in the English
alphabet in identifiers. However, if you're writing code in your native
langauge, you may need to use other letters as well. To be able to
use the replacement characters in ISO 646 would be nice, but it would
be pointless to require that.
But with eight-bit sets in 8859, it is a fair requirement that all
letters in these sets also are permitted in identifier names.
The problem lies in the difference between the sets. In Latin-1
161-191 are punctuation characters which you normally wouldn't think of
in identifier names. 192-255 are letters, with 32 as difference between
lower and upper case. (A few exceptions which I disregard here for
brevity.)
In the other Latin sets, some characters in the range 161-191 are
also letters, with 16 as the case difference.
How the non-Latin sets look like I don't know.
One could make this a very simple issue and just take Latin-1, with
the motivation that is what will be used in the known world of computing.
However, I think this would be fatal mistake. Should our friends in
Hungary, Russia and Greece be handicapped in the selection of
identifier characters? Do we know that "the known world of computing"
will forever restrict itself to to places were Western European
langauges are spoken?
Now then, how to support mulitple sets? An idea would be to have a
directive that said which character set the source code was written with.
We must of course immediately discard the idea, since this is impossible
in a modular langauge like Eiffel. (What if we want to inherit that
Latin-2 class in our Latin-1 class?)
As far as I can see the only way to go is to allow all characters
>= 161 and then use the 32 and 16 differences for case folding. (A
case significant language like C or Modula-2 has some advantage here.)
!
Operations
----------
When comparing two strings the collating sequence often has little
relevance with the alphabet. The only languages I know it works for
using ISO 646 are English, Danish, Norwegian and maybe Dutch. As a
whole one should remember that the character type in this sense is
not a simple enumerate. In many languages you only take regard to
accents and umlauts when no other character is different. And some
langauges have pairs of letters that sorts as one. (E.g. "ch" in
Spanish, "rz" in Polish.)
What you need is a set of extended comparison routines, a set of
predefined langauges and a set of routines for loading your very
own sorting order. Eiffel is extremely well prepared in this area,
particulary with the additions of infix operators in 2.2. So all
that is needed is some additions to the class library. Of course
I could write them myself, but I think they should be in the
standard library, since this is the way strings should be compared.
Using the collating sequence is a very artificial way to do it.
Or, is library additions really all we need? If we define a class
TRANSCRIPTED_STRING which codes a string to some internal format
for comparisons we would like to write:
t_str : TRANSCRIPTED_STRING;
...
t_str := "Some string";
But even if our new class is an heir of STRING, the assignment is
not permitted. And defining a TRANSCRIPTED_CHARACTER for single
elements as an heir to CHARACTER is out the question, since the
latter class is an expanded one and may not be inherited from.
One solution to these problems would of course be to inlcude
the required operations within STRING and CHARACTER. There are
probably some performance penalty for Americans who don't want
more than simple ASCII comparison, but it's certainly a solution
that looks very appealing.
It should be added here, that there are various operating systems,
not the least in the Unix sphere, that supports handling of more
than one human language which includes run-time support for
comparisons. But they are often intended for C and Eiffel gives
room for much cleaner interfaces.
In this article I have discussed very little of multi-byte characters,
since I have no experience of using them. However, they should not be
forgotten when addressing these problems. They write programs in Japan
too.
--
Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se
Bowlers on strike!
∂11-Jul-89 0951 @mc.lcs.mit.edu,@ZURICH.ai.mit.edu:mkatz@sesame.stanford.edu Regularization of list, vector, and string procedures
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 11 Jul 89 09:51:34 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa11726;
11 Jul 89 12:34 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 11 Jul 89 12:21:14 EDT
Received: from ZURICH.AI.MIT.EDU by mintaka.lcs.mit.edu id aa11475;
11 Jul 89 12:16 EDT
Return-Path: <mkatz@sesame.Stanford.EDU>
Received: from sesame.Stanford.EDU (sesame.stanford.edu) by ZURICH.AI.MIT.EDU; Tue, 11 Jul 89 12:12:17 edt
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA17846; Tue, 11 Jul 89 09:14:32 PDT
Date: Tue, 11 Jul 89 09:14:32 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8907111614.AA17846@sesame.Stanford.EDU>
To: rrrs-authors@ZURICH.ai.mit.edu
Subject: Regularization of list, vector, and string procedures
At Jim Miller's request I am reposting a slightly cleaned up version of my
original proposal for regularization of the list, vector, and string procedures
in Scheme.
-------------------------------------------------------------------------------
For those of you who don't remember, I was assigned the task at L&FP to
regularize the procedures involving lists, strings, and vectors for R4RS.
Initially, this looked like a trivial, noncontroversial task; but, it turns out
that there are actually some important semantic issues to be discussed. I have
therefore decided to pass my ideas before the entire community, rather than
just sending them straight to the editors.
I will begin this discussion with what I believe are the noncontroversial
changes and then proceed to the Controversial ones. In order to better
understand the issues I have included the chart below which enumerates the
relevant procedures currently in R3RS.
LIST STRING VECTOR
---- ------ ------
list vector
make-string make-vector
string-fill vector-fill
list-ref string-ref vector-ref
string-set! vector-set!
string-copy
length string-length vector-length
append string-append
append!
list->string string->list vector->list
list->vector
reverse
substring
string=?
string? vector?
apply
map, foreach
memq, memv, member
assq, assv, assoc
Noncontroversial:
1) Add string, make-list, list-fill, list-set!, list-copy, vector-copy,
vector-append, string->vector, and vector->string with the obvious
semantics.
2) Create aliases list-length and list-append for length and append,
respectively.
3) Append! should NOT be generalized since most implementations (for good
reasons) represent strings and vectors in a manner that is incompatible
with append! semantics.
4) Reverse should NOT be generalized since the extensions would be pretty much
useless.
5) Sublist and subvector should be added because they are potentially useful
and the implementations in scheme are much less efficient than ones which
could be supplied by an implementor.
6) String=? is only present for symetry with string-ci=? and should NOT be
generalized to list=? and vector=? since we already have =?.
Controversial:
1) Create list? which checks for a null terminated list. This CAN be written
by a user and is only marginally useful, but I believe it is important that
it exist for symetry reasons.
2) Generalize apply:
(apply proc args)
(apply proc arg1 arg2 ... args)
ARGS could be any of a list, string, or vector whose elements would be
spread before the actual application was performed.
3) There are several possibilities for map and foreach:
a) Status quo
b) Introduce list-map, string-map, vector-map, list-foreach,
string-foreach, and vector-foreach. List-map and list-foreach would be
identical to the current map and foreach, respectively. The others
would have the following syntaxes and semantics
(string-map proc string1 string2 ...)
(vector-map proc vector1 vector2 ...)
(string-foreach proc string1 string2 ...)
(vector-foreach proc vector1 vector2 ...)
The string version would take strings as arguments and in the case of
string-map would return a string. The vector versions would do
similarly. It would be a type error to pass a string to list-map, a
list to vector-map, etc.
c) The same 6 procedures would be introduced as in b). In this case the
name would specify the type of the return value. The procedures would
be polymorphic over arguments of type list, string, and vector. All
that would be required would be that the arguments all have the same
length.
I am personally in favor of either b) or c). I like the semantics of c),
but realize that some members of the community may find this semantics
objectionable.
4) Memq, memv, and member are quite problematic. They could be extended to
allow the second argument to be a vector in the obvious way, but then what
should they return on a match. Returning a subvector is unsatisfactory
because the aliasing one gets with a sublist would undoubtedly not be
present for a subvector, and thus the original structure could not be
modified based on the result. In my experience, this is one of the most
common uses for these procedures and it would be negated. Another
alternative is just to return #t and #f. However, this seems to be
unintuitively incompatible with the original versions. Extensions for
strings are even worse, because the equivalence distinctions between eq,
eqv, and equal are not present and have instead been replaced by case
sensativity and insensitivity. MY RECOMMENDATION IS TO MAKE NO EXTENSION.
5) Any extensions to assq, assv, and assoc have similar problems to those of
memq, etc. and I therefore again RECOMMEND NO EXTENSION.
6) As a result of 5) and 6), I suggest adding two new families of procedures
which for the sake of exposition I will call member? and match. (I know
these are horrible names, but if people like the idea, we'll worry about
what to call them later.) Their syntaxes would be as follows:
(list-member? val pred list)
(string-member? val pred string)
(vector-member? val pred vector)
(list-match val pred list)
(string-match val pred string)
(vector-match val pred string)
The member procedures would return #f if (pred val (foo-ref foo i))
returned #f for all i, where foo is either list, string, or vector.
Otherwise, they would return #t. The match procedures would perform
similarly except that they would return the first element for which pred
returned #t, #f otherwise. A decision would have to be made for match as
to whether each element of a vector would have to itself be a vector.
Obviously, for strings each element would have to be a character and so
this version would be somewhat useless. As A RESULT, I propose that
instead we introduce just the procedures member? and match which are
polymorphic over all the reasonable types (i.e., strings, vectors, and
lists). For match, this polymorphism would extend 2 levels into the
data structure.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂11-Jul-89 1100 @MC.lcs.mit.edu,@mojave.stanford.edu:shap@sid.stanford.edu Fluid binding
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 11 Jul 89 11:00:01 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa12852;
11 Jul 89 13:42 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 11 Jul 89 13:36:59 EDT
Received: from Mojave.Stanford.EDU by mintaka.lcs.mit.edu id aa12788;
11 Jul 89 13:32 EDT
Received: from sid.Stanford.EDU by mojave.Stanford.EDU (5.59/inc-1.0)
id AA04778; Tue, 11 Jul 89 10:29:52 PDT
Message-Id: <8907111729.AA04778@mojave.Stanford.EDU>
Received: by sid; Tue, 11 Jul 89 10:32:27 pdt
Date: Tue, 11 Jul 89 10:32:27 pdt
From: "Jonathan S. Shapiro" <shap@sid.stanford.edu>
To: jinx@ZURICH.ai.mit.edu
Cc: Pavel.pa@xerox.com, rrrs-authors@MC.lcs.mit.edu
In-Reply-To: "Guillermo J. Rozas"'s message of Sun, 9 Jul 89 00:50:33 edt <8907090450.AA01092@ZURICH.AI.MIT.EDU>
Subject: Fluid binding
Points well taken. Thanks jinx.
My qualm about the proposal sent out boils down to the fact that it
seems like it would be cumbersome to use, but since I don't have a
better idea, I withdraw my objections.
Jon
∂11-Jul-89 1105 @MC.lcs.mit.edu,@ZURICH.ai.mit.edu:shap@sid.stanford.edu International character sets.
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 11 Jul 89 11:05:39 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa12943;
11 Jul 89 13:49 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 11 Jul 89 13:24:27 EDT
Received: from ZURICH.AI.MIT.EDU by mintaka.lcs.mit.edu id aa12619;
11 Jul 89 13:21 EDT
Return-Path: <shap@sid.STANFORD.EDU>
Received: from mojave.Stanford.EDU (mojave.stanford.edu) by ZURICH.AI.MIT.EDU; Tue, 11 Jul 89 13:18:36 edt
Received: from sid.Stanford.EDU by mojave.Stanford.EDU (5.59/inc-1.0)
id AA04739; Tue, 11 Jul 89 10:18:38 PDT
Message-Id: <8907111718.AA04739@mojave.Stanford.EDU>
Received: by sid; Tue, 11 Jul 89 10:21:13 pdt
Date: Tue, 11 Jul 89 10:21:13 pdt
From: "Jonathan S. Shapiro" <shap@sid.stanford.edu>
To: rrrs-authors@ZURICH.ai.mit.edu
Subject: International character sets.
If anyone thinks it would help the discussion, I would be more than
happy to send out a description of the solution that was adopted for
ANSI-C, and put forth a proposal whose purpose is only to act as a
basis for discussion describing how we might adapt it to Scheme.
Jon
∂11-Jul-89 1136 @mc.lcs.mit.edu,@ZURICH.ai.mit.edu:jar@annabel.stanford.edu Regularization of list, vector, and string procedures
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 11 Jul 89 11:36:46 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa13758;
11 Jul 89 14:24 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 11 Jul 89 14:21:04 EDT
Received: from ZURICH.AI.MIT.EDU by mintaka.lcs.mit.edu id aa13695;
11 Jul 89 14:15 EDT
Return-Path: <jar@annabel.stanford.edu>
Received: from sonoma.Stanford.EDU ([36.22.0.158]) by ZURICH.AI.MIT.EDU; Tue, 11 Jul 89 14:12:48 edt
Received: by sonoma.Stanford.EDU (5.57/Ultrix2.4-C)
id AA02184; Tue, 11 Jul 89 10:13:37 PDT
Message-Id: <8907111713.AA02184@sonoma.Stanford.EDU>
Received: from annabel.STANFORD.EDU by dolores; Tue, 11 Jul 89 10:14:22 pdt
Received: by annabel; Tue, 11 Jul 89 10:12:25 pdt
Date: Tue, 11 Jul 89 10:12:25 pdt
To: mkatz@sesame.stanford.edu
Cc: rrrs-authors@ZURICH.ai.mit.edu
In-Reply-To: Morris Katz's message of Tue, 11 Jul 89 09:14:32 PDT <8907111614.AA17846@sesame.Stanford.EDU>
Subject: Regularization of list, vector, and string procedures
From: Jonathan Rees <jar%sid.stanford.edu@polya.stanford.edu>
Sender: jar@annabel.stanford.edu
(It looks like you might not have the final version of the Revised↑3
Report. append! and =? were both flushed at the last minute. The
version that was given out at the '86 LFP conference was unfortunately
not the final version, so anyone who has one should discard it.)
I have no real problem with the "noncontroversial" changes you
enumerate, although I can't imagine any use for string->vector or
vector->string.
Generalizing apply to be generic over the type of the last argument
would constitute a strong precendent for the introduction of other
generic sequence functions, a la Common Lisp. I would prefer not to
see that happen, thus I'd rather that apply be left alone. Similarly,
I'd rather not see generic member or match.
I would rather not see any extensions to the map/for-each line that
don't do the real job, which is to improve the ways in which we can
write iterations.
∂11-Jul-89 2148 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #156
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 11 Jul 89 21:48:05 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa01797;
12 Jul 89 0:38 EDT
Date: 12 JUL 89 00:10:54 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #156
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID: <8907120038.aa01797@mintaka.lcs.mit.edu>
Scheme Digest #156 12 JUL 89 00:10:54 EDT
Today's Topics:
Scheme Digest #147
----------------------------------------------------------------------
Date: Tue, 11 Jul 89 10:21:15 EST
From: "John T. Nelson" <jtn@potomac.ads.com>
Message-Id: <8907111521.AA25882@potomac.ads.com>
Subject: Re: Scheme Digest #147
If you have a pointer to the FTP'able Scheme report and/or public
domain Scheme I'd appreciate hearing about it.
------------------------------
End of Scheme Digest
********************
∂12-Jul-89 1325 @mc.lcs.mit.edu:Pavel.pa@xerox.com Fluid binding
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 12 Jul 89 13:25:09 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa21337;
12 Jul 89 16:19 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 12 Jul 89 16:16:00 EDT
Received: from Xerox.COM by mintaka.lcs.mit.edu id aa21211; 12 Jul 89 16:12 EDT
Received: from Cabernet.ms by ArpaGateway.ms ; 12 JUL 89 11:00:17 PDT
Date: Wed, 12 Jul 89 11:00:52 PDT
From: Pavel.pa@xerox.com
Subject: Fluid binding
In-reply-to: <8907061641.AA25714@sesame.Stanford.EDU>
To: rrrs-authors@mc.lcs.mit.edu
Message-ID: <890712-110017-1659@Xerox>
Morry asks for a better argument as to why shallow binding cannot be used
on shared-memory multiprocessors. It seems fairly clear to me. Consider
two threads, running on separate processors, both within the scope of a
particular lexical variable, X. When either thread assigns to X, obviously
the other thread should get the new value when it reads X. When one thread
fluid-binds X, though, it has, in effect, a new variable with the same name
over some dynamic extent; changes to the new variable should NOT be visible
to the other thread. In shallow binding, however, the new variable uses
the same storage as the old one and its ``temporary assignment'' cannot be
distinguished from any other assignment. Thus, the new value WILL be
visible to the other thread, in contradiction to the desired behavior. I
thus conclude that shallow binding is not a viable approach for fluid
variables on a shared-memory multiprocessor.
Jinx had some interesting comments:
1) MAKE-FLUID, FLUID-REF and FLUID-SET! don't have much to do with
fluids, they have to do with cells (or boxes, as some other people
call them). As such, I would like them to be renamed to
MAKE-CELL, CELL-REF, and CELL-SET!.
Alternatively we could have both MAKE-CELL, CELL-REF, CELL-SET! to
manipulate cells (the selector and mutator always provide the global
value), and FLUID-CELL-REF, FLUID-CELL-SET! to access the current
dynamic value. Which of the accessors is written on top of which
depends on whether the implementation is deep or shallow.
When I first read this, it seemed very reasonable. On later thought,
however, I concluded otherwise. For the first paragraph, I think that,
conceptually, MAKE-FLUID, FLUID-REF and FLUID-SET! have nothing to do with
cells at all. Rather, they traffic in ``fluid variables'', opaque values
that are the domain of the ``fluid environment'' (the range is locations,
just as in the lexical environment). Certainly one implementation of these
procedures (and the one I would use) has MAKE-FLUID return a cell, as you
suggest, but I think renaming them in terms of cells is a convolution of
their abstract semantics with one particular concrete realization.
I have additional problems with idea in the second paragraph. In a
shallow-binding implementation, CELL-REF is identical to FLUID-CELL-REF
while in a deep-binding implementation, their semantics is quite different.
I think it unwise for the language semantics to change depending upon a
property of the implementation that should be completely invisible.
I think that, if we want to add cells as a standard data type in the
language, we should do so separately.
2) Although I admit that FLUID-LET would be the most common way of
obtaining dynamic behavior, I'd rather have it be a simple macro that
expands into a standard procedure. In particular, I would like to
have
(FLUID-LET ((<var-expr1> <val-expr1>)
(<var-expr2> <val-expr2>)
... )
<body>)
expand into something like
(with-cell-contents
(list var-expr1 var-expr2 ...)
(list val-expr1 val-expr2 ...)
(lambda ()
<body>))
I don't object to this in principle, but I'd rather a somewhat simpler
primitive that doesn't promote lists in this way. For example, the
following:
(fluid-let ((<var-expr1> <val-expr1>)
(<var-expr2> <val-expr2>)
...
(<var-exprN> <val-exprN>))
<body>)
expands into
(let ((var1 <var-expr1>)
(val1 <val-expr1>)
(var2 <var-expr2>)
(val2 <val-expr2>)
...
(varN <var-exprN>)
(valN <val-exprN>)
(body-thunk (lambda () <body>)))
(with-fluid-binding var1 val1
(lambda ()
(with-fluid-binding var2 val2
(lambda ()
...
(with-fluid-binding varN valN
body-thunk) ... )))))
That is, I prefer a primitive that establishes exactly one binding at a
time. Also, since I conceive of this construct in terms of new bindings in
the fluid environment, as opposed to changing the ``contents'' of anything,
a prefer a name for the primitive that says so. Thus my
``with-fluid-binding'' in contrast to Jinx's ``with-cell-contents''.
3) There are many incompatible versions of FLUID-LET out there, so I
think we should use a different name for it so that existing
implementations can continue using their code without having to
rewrite it and can provide two different mechanisms, the standard, and
the old one. I would suggest WITH-FLUID-CONTENTS or something like
that, but I'm not good at choosing names.
Cedar Scheme is one of those implementations with an incompatible construct
called FLUID-LET, so we would have to rewrite our code as well, but I don't
anticipate it being very hard to do. It seems to me that a very simple
global query-replace could be used to change all of the uses of the old
construct to use a different name. That way, the new standard construct
can use the stylistically correct and appropriate name and old code need
not be rewritten. For example, we might rename our old construct to
SHALLOW-BIND... (Unlike Scheme Xerox, our new implementation, Cedar Scheme
does not support multiple threads of execution.)
I think it's important, when we reach consensus on a feature with which
we've all experimented, that we can reasonably expect some implementations
to change for the new standard.
================
I believe that the above discussion answers all standing comments on the
fluid binding proposal. Are there any further comments or responses to the
above?
Pavel
∂12-Jul-89 1400 @mc.lcs.mit.edu,@LIFE.ai.mit.edu:cph@zurich.ai.mit.edu scheme mailing list
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 12 Jul 89 14:00:16 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22080;
12 Jul 89 16:51 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 12 Jul 89 16:45:56 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa21962;
12 Jul 89 16:43 EDT
Received: from ZURICH.AI.MIT.EDU ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA02542; Wed, 12 Jul 89 16:23:08 EDT
Return-Path: <cph@ZURICH.AI.MIT.EDU>
Received: by ZURICH.AI.MIT.EDU; Wed, 12 Jul 89 16:20:03 edt
Date: Wed, 12 Jul 89 16:20:03 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
Message-Id: <8907122020.AA13254@ZURICH.AI.MIT.EDU>
To: pavel.pa@xerox.com
Cc: scheme-standard@LIFE.ai.mit.edu, rrrs-authors@LIFE.ai.mit.edu
In-Reply-To: Chris Haynes's message of Wed, 12 Jul 89 12:09:16 -0500
Subject: scheme mailing list
Date: Wed, 12 Jul 89 12:09:16 -0500
From: Chris Haynes <chaynes@iuvax.cs.indiana.edu>
Date: Thu, 06 Jul 89 18:52:11 PDT
From: Pavel.pa@Xerox.COM
Chris, can you add someone to the Scheme-Standard mailing list? I've tried
writing to scheme-standard-request@mc.lcs.mit.edu (but it doesn't exist)
and cph@kleph.ai.mit.edu (but got nasty mailer failures).
I'd like to see my summer intern, Jim Rauen <Rauen.pa@Xerox.Com>, have
access to both scheme-standard and rrrs-authors; so far, I haven't managed
to succeed at either of them. Sigh.
Thanks,
Pavel
The correct address is
scheme-standard-request@wheaties.ai.mit.edu
My correct address is
cph@zurich.ai.mit.edu
(recent system reconfiguration prevents "kleph" from accepting mail).
I've added rauen to "scheme-standard".
I have to look into "rrrs-authors" -- JAR left me in charge of it
while he's away.
I've set things up so that the following addresses will work,
forwarding mail to the appropriate mailing lists. I may actually move
the lists to this machine for ease of maintainance.
rrrs-authors@life.ai.mit.edu
rrrs-authors-request@life.ai.mit.edu
scheme@life.ai.mit.edu
scheme-request@life.ai.mit.edu
∂12-Jul-89 1433 @mc.lcs.mit.edu,@decwrl.dec.com:jmiller@crl.dec.com R↑3.95RS: open-input-file open-output-file
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 12 Jul 89 14:33:09 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22672;
12 Jul 89 17:28 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 12 Jul 89 17:24:43 EDT
Received: from decwrl.dec.com by mintaka.lcs.mit.edu id aa22596;
12 Jul 89 17:22 EDT
Received: from crl.crl.dec.com by decwrl.dec.com (5.54.5/4.7.34)
id AA02411; Wed, 12 Jul 89 14:22:24 PDT
Received: from crl.crl.dec.com by decwrl.dec.com (5.54.5/4.7.34)
for rrrs-authors@mc.lcs.mit.edu; id AA02411; Wed, 12 Jul 89 14:22:24 PDT
Received: by crl.crl.dec.com (5.57/Ultrix2.4-C)
id AA01036; Tue, 11 Jul 89 13:56:11 EDT
Date: Tue, 11 Jul 89 13:57:19 EDT
From: jmiller@crl.dec.com
Message-Id: <8907111757.AA00833@peanut.DEC.COM>
To: Alan@reagan.ai.mit.edu
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Alan Bawden 10-Jul-89 1709 EDT's message of Tue, 11 Jul 89 03:57:03 EDT <8907110757.AA00450@crl.crl.dec.com>
Subject: R↑3.95RS: open-input-file open-output-file
Reply-To: JMiller@crl.enet.dec.com
I agree completely with you. One of the things that Scheme needs is a
"reasonable" error (condition, exception, take your pick) system. In
lieu of that, which I suspect will take some time to agree upon, I
believe we need a mechanism for PORTABLE programs to use procedures
that SIGNAL an error. There are very few such procedures: only these
two (OPEN-[IN/OUT]PUT-FILE), two similar ones that can be built on top
of these (CALL-WITH-[IN/OUT]PUT-FILE), and READ. In addition, numeric
operations are permitted to signal an error when they reach
implementation limits on representations.
Is it really a high price to pay, pending agreement on an error
system, to allow a portable mechanism for detecting the errors
generated by OPEN-[IN/OUT]PUT-FILE? Notice that my proposal would not
make this the default behavior: only with explicit programmer action
would it be possible to receive a value of #F instead of an error.
Making this change would allow programs, for example, to try
alternative file names given a root file name (this allows porting
across Scheme implementations, not operating systems). A similar
change to READ would allow portable programs to recover from user
input errors.
--Jim
∂12-Jul-89 1444 @mc.lcs.mit.edu,@decwrl.dec.com:jmiller@crl.dec.com EQV? and =
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 12 Jul 89 14:44:37 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22908;
12 Jul 89 17:38 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 12 Jul 89 17:24:50 EDT
Received: from decwrl.dec.com by mintaka.lcs.mit.edu id aa22598;
12 Jul 89 17:23 EDT
Received: from crl.crl.dec.com by decwrl.dec.com (5.54.5/4.7.34)
id AA02503; Wed, 12 Jul 89 14:22:55 PDT
Received: from crl.crl.dec.com by decwrl.dec.com (5.54.5/4.7.34)
for rrrs-authors@mc.lcs.mit.edu; id AA02503; Wed, 12 Jul 89 14:22:55 PDT
Received: by crl.crl.dec.com (5.57/Ultrix2.4-C)
id AA01246; Tue, 11 Jul 89 16:54:54 EDT
Date: Tue, 11 Jul 89 16:56:02 EDT
From: jmiller@crl.dec.com
Message-Id: <8907112056.AA00888@peanut.DEC.COM>
To: rrrs-authors@mc.lcs.mit.edu
Subject: EQV? and =
Reply-To: JMiller@crl.enet.dec.com
I thought that
(and (number? x) (number? y) (= x y)) implied
(eqv? x y).
By my reading of R3.95RS this isn't true (consider x=3 and y=3.0),
although I believe
(and (number? x) (number? y) (eqv? x y)) implies
(= x y)
Have I got this right?
--Jim
∂12-Jul-89 1716 @mc.lcs.mit.edu,@life.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu last call: changes for R4RS
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 12 Jul 89 17:16:36 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa24940;
12 Jul 89 20:12 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 12 Jul 89 20:09:01 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa24788;
12 Jul 89 20:03 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA03806; Wed, 12 Jul 89 20:03:45 EDT
Return-Path: <@spencer.cs.uoregon.edu:will@cs.uoregon.edu>
Received: from skinner.cs.uoregon.edu ([128.223.4.13]) by zurich.ai.mit.edu; Wed, 12 Jul 89 20:00:43 edt
Received: from spencer.cs.uoregon.edu by skinner.cs.uoregon.edu with SMTP
(5.59++/IDA-1.2.8) id AA20470; Wed, 12 Jul 89 17:03:12 PDT
Received: by spencer.cs.uoregon.edu; Wed, 12 Jul 89 17:03:23 PDT
Date: Wed, 12 Jul 89 17:03:23 PDT
From: will@cs.uoregon.edu
Message-Id: <8907130003.AA17137@spencer.cs.uoregon.edu>
To: rrrs-authors@zurich.ai.mit.edu
Subject: last call: changes for R4RS
The P1178 working group on Scheme has requested a few more changes to the
R3.95RS before it becomes the R4RS. From the votes taken at P1178, I
judge that two of these changes are sufficiently controversial that they
will require positive action by the authors to be adopted. The other
changes that were requested appear to be noncontroversial, and I will
implement these other changes unless the authors object.
I have promised the P1178 editors that I will deliver the final draft of
the R4RS to them by the end of July so they can incorporate it into the
IEEE standard they're drafting. So if you want to influence the R4RS,
you'd better send mail to RRRS-AUTHORS within the next two weeks.
I will be off the net during that time because my department is moving
into a new building this weekend, and the computers will be shut down
until the move is completed. I have made arrangements to read mail sent
to RRRS-AUTHORS during that time, but I will be unable to send mail myself.
Peace,
William Clinger
(503) 345-6995 (home)
--------------------------------------------------------------------------------
Controversial changes requiring positive action by the authors if they are
to be adopted in the R4RS:
Section 6.3.
P1178 has requested again that LIST-REF be made essential, for parallelism
with VECTOR-REF and STRING-REF. Their previous request that LIST-TAIL be
made essential has been dropped.
Section 6.5.5.
P1178 has requested that MIN and MAX be renamed INF and SUP. The rationale
is that the somewhat surprising behavior of MIN and MAX when given mixed
exact and inexact arguments would be more acceptable if their names were
less familiar. A second rationale is that the fact that the mathematical
infimum and supremum operations, when given an infinite set of "arguments",
may return a result that is not in the argument set; this is the surprising
thing about MIN and MAX, e.g. (MAX 1.4 #e1e100) ==> 9.999999999999998e99.
Background: In any case, a note will be added to point out and explain this
behavior, which is required in order for exact results to be trusted. It
happens that MIN and MAX behave this way in Common Lisp as well, although
the motivation was rather different.
--------------------------------------------------------------------------------
Noncontroversial changes that will be adopted in the R4RS unless the authors
object:
Section 6.5.3.
EXPT will be added to the list of procedures that are required to return
an exact integer if all their arguments are exact and the mathematically
expected result is representable as an exact integer within the
implementation. Examples of what will be newly required:
(expt 2 3) --> 8 ; exact 8
(expt -3 0) --> 1 ; exact 1
(expt 1 -20) --> 1 ; exact 1
Section 6.5.5.
If a variable x has a proper number as its value, then (= x x) will be
required to be true. Note: "proper number" is intended to exclude NaNs
et cetera. [Alternatively we could require NUMBER?---and therefore
REAL?---to be false of NaNs. I'd rather not try to specify this level
of detail until we have more experience with non-IEEE implementations
of inexact arithmetic.]
Section 6.2.
EQV?-ness is preserved when storing into and fetching from the standard
data structures (pairs, vectors, strings). [Note: EQ?-ness isn't
necessarily preserved. Preservation of EQV?-ness implies preservation
of exactness, which is the context in which P1178 requested this change.]
P1178 and individuals also pointed out several places where editorial
changes would improve the presentation, but none of these changes affect
the content so I'm not going to list them here.
--------------------------------------------------------------------------------
Summary of substantive changes that I have posted in previous messages:
Add ... as a new peculiar identifier.
Change branch cuts for ATAN.
Require INTEGER->CHAR and CHAR->INTEGER be one-to-one.
Restore CHAR-UPPER-CASE?.
Make the truth value of the empty list be unspecified.
Fix the second production for <decimal 10>.
Change the specification of NUMBER->STRING to fix bugs pointed out by
Kent Dybvig.
∂12-Jul-89 1731 @mc.lcs.mit.edu,@life.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu legion
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 12 Jul 89 17:31:02 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa25119;
12 Jul 89 20:22 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 12 Jul 89 20:09:18 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa24819;
12 Jul 89 20:06 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA03862; Wed, 12 Jul 89 20:05:55 EDT
Return-Path: <@spencer.cs.uoregon.edu:will@cs.uoregon.edu>
Received: from skinner.cs.uoregon.edu ([128.223.4.13]) by zurich.ai.mit.edu; Wed, 12 Jul 89 20:02:56 edt
Received: from spencer.cs.uoregon.edu by skinner.cs.uoregon.edu with SMTP
(5.59++/IDA-1.2.8) id AA20486; Wed, 12 Jul 89 17:05:28 PDT
Received: by spencer.cs.uoregon.edu; Wed, 12 Jul 89 17:05:39 PDT
Date: Wed, 12 Jul 89 17:05:39 PDT
From: will@cs.uoregon.edu
Message-Id: <8907130005.AA17154@spencer.cs.uoregon.edu>
To: rrrs-authors@ZURICH.ai.mit.edu
Subject: legion
In response to Pavel's sermon/supplication, here is what I think of some
of the ideas that have been mooted about recently.
If indeed we must add fluid variables to the language, then I think that
we should do something very like Pavel's proposal. I'm not keen on
adding fluid variables, however. If we are to add any dynamic features
I'd rather add DYNAMIC-WIND, which seems simpler and more useful. If
we had DYNAMIC-WIND and a macro package, then people could pull their
favorite semantics for fluid variables out of the yellow pages.
Jinx:
...I'll state my position, which I believe coincides with his and
was the consensus of most implementors a while ago.
An implementation that does not allow assignment of the initial
variables (including those bound to procedures) in an RnRs environment
is in ERROR....It is acceptable, however, for an implementation to
default to "benchmark" mode, as long as the following two conditions
are met:
1) There is a way to take it out of benchmark mode.
2) Appropriate warnings about redefinition/warning are given when the
implementation is in benchmark mode and an assignment/redefinition is
"attempted".
I agree with this statement. I would add to it that while the number
of people who need to get out of benchmark mode is very small, they
usually have pretty good reasons for wanting to escape from it.
Furthermore it isn't very hard to design a Scheme system so that the
vast majority of users who run in benchmark mode do not lose any
performance as a result of the tiny minority who need to escape from it.
Pavel:
...The way you'll lose horribly in Scheme Xerox is that your program
won't compile. I'm not asking R4RS to prohibit redefinition, I'm
simply asking it to let me do so in my own implementation.
It is perfectly all right for your compiler to prohibit redefinition,
so long as your system provides a second mode in which redefinition is
allowed. The second mode doesn't have to be fast. It could be
implemented by a pure interpreter layered on top of everything else,
using an entirely separate environment. Furthermore you could require
that users who wish to program in non-benchmark mode must do so by
loading the interpreter interactively and calling a special
read/eval/print loop. In other words, the requirement you've been so
concerned about is absolutely trivial. You should go ahead and build
your system however you want, and implement the non-benchmark mode
after you've got everything else running.
Jinx:
I think most people would agree that R4RS as it currently stands is a
toy language. Besides macros, fluid binding and other well known
conveniences, it lacks any practical way of separating large programs
into semi-independent subprograms without exporting zillions of names
into the top level environment.
I do not agree that R4RS is a toy language. Compare it to C: Scheme's
unrestricted block structure, together with the first-class-ness of all
objects that allows a locally defined object to be stored into a global
variable, provides at least as much control over names as you get with
C. C doesn't have fluid variables, nor does it have environments, nor
does it have EVAL, et cetera. C has macros, but if C's macros are the
decisive feature that makes C a non-toy language then we can trivially
make R4RS into a non-toy language by wedding it to the C preprocessor.
Scheme is deficient in several ways, but we can justify proposed
improvements without characterizing the existing language as a toy.
Pavel:
...the user cannot portably assign to (or even rebind) variables
named ``if'', ``or'', ``delay'', or even ``unquote''...
Morry:
This is one of the reasons we need macros. As soon as we have them,
I will be able to override the default definitions for special forms
as well.
This is speculation, since not all macro facilities allow this override.
Common Lisp provides an example.
Jinx:
We've been trying to fix this for quite a while. It has not been
fixed in R4RS because of political and technical problems having to do
with the actual solutions suggested, not because we don't agree that
this should be fixed.
I am not convinced that it should be fixed. So long as the set of
syntactic keywords is very small, keeping them reserved contributes to
readability. It also appears that the various macro facilities that
have been proposed would be significantly easier to use correctly if
syntactic keywords remain reserved. In fact, I believe that one of
the main reasons we don't yet have a standard macro facility is that
too much effort has been devoted to the difficulties that arise only
when syntactic keywords can be shadowed by lexical variables.
Jim Miller:
I'd like to suggest that Pavel use "|" instead of ":" for his module
separator.
I thought this was an excellent suggestion. In addition to the four
reserved brackets ([, ], {, }), the three varieties of quote mark
(", ', `), and the comma, there are four very usable characters
available for extending the lexical syntax of identifiers: | @ # \.
If an implementation consumes these four and is still hungry for more,
then I doubt we can appease it for long by feeding it a colon.
Will:
2. (This reason is pretty weak.) For the compiler writer, I
think the freedom to rearrange definitions makes closure
analysis a little simpler when procedure definitions are
mixed with definitions of variables containing non-procedure
values.
This is incorrect. The compiler would still have the freedom to move
procedure definitions in front of other definitions, since it could
make a difference only if the program is in error. Once the procedure
definitions have been grouped together, their order makes no difference
under either semantics.
Peace, Will
∂12-Jul-89 1745 @mc.lcs.mit.edu,@life.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu Regularization of list, vector, and string procedures
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 12 Jul 89 17:45:24 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa25254;
12 Jul 89 20:32 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 12 Jul 89 20:09:33 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa24837;
12 Jul 89 20:08 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA03872; Wed, 12 Jul 89 20:08:06 EDT
Return-Path: <@spencer.cs.uoregon.edu:will@cs.uoregon.edu>
Received: from skinner.cs.uoregon.edu ([128.223.4.13]) by zurich.ai.mit.edu; Wed, 12 Jul 89 20:05:07 edt
Received: from spencer.cs.uoregon.edu by skinner.cs.uoregon.edu with SMTP
(5.59++/IDA-1.2.8) id AA20496; Wed, 12 Jul 89 17:07:37 PDT
Received: by spencer.cs.uoregon.edu; Wed, 12 Jul 89 17:07:48 PDT
Date: Wed, 12 Jul 89 17:07:48 PDT
From: will@cs.uoregon.edu
Message-Id: <8907130007.AA17164@spencer.cs.uoregon.edu>
To: rrrs-authors@zurich.ai.mit.edu
Subject: Regularization of list, vector, and string procedures
Cc: mkatz@sesame.stanford.edu
6) String=? is only present for symetry with string-ci=? and should NOT
be generalized to list=? and vector=? since we already have =?.
I think you meant EQUAL? instead of =?.
1) Create list? which checks for a null terminated list...
This is useful. I prefer the name PROPER-LIST?.
2) Generalize apply...[to be generic in the last argument]
I'd prefer to avoid generic procedures at the lowest levels of Scheme.
Why not have LIST-APPLY, VECTOR-APPLY, and STRING-APPLY, by analogy with
LIST-LENGTH, VECTOR-LENGTH, and STRING-LENGTH etc?
3) There are several possibilities for map and foreach:
a) ...
b) Introduce list-map, string-map, vector-map, list-foreach,
string-foreach, and vector-foreach...
c) The same 6 procedures would be introduced as in b). In this
case the name would specify the type of the return value.
The procedures would be polymorphic over arguments of type
list, string, and vector...
In c), it doesn't make sense to have three versions of FOR-EACH distinguished
by the type of their return value, since presumably the return value is
unspecified in each case. Again, I'd prefer type-specific procedures over
generic procedures, because the types are usually known and something like
(VECTOR-FOREACH F V1 V2) conveys more information than (FOREACH F V1 V2).
As a practical matter, the type-specific procedures would have to exist
anyway, and the question is whether the programmer gets to refer to them
directly or must go through a generic interface that obscures the type
information.
The argument in favor of generic procedures is that there would have to be
3 type-specific versions of FOR-EACH and 9 type-specific versions of MAP
even if all the arguments to these procedures are required to be of the
same type. It gets worse if we relax that requirement or if we add more
sequence types.
Here's a counter-proposal: define MAKE-FOREACH and MAKE-MAP that take a
description of the argument and result types for the FOR-EACH or MAP
procedure needed and return the appropriate FOR-EACH or MAP procedure.
Implementations would then be free to special-case these procedures as much
as they feel is necessary, using EQ? tests on the arguments. Sample
implementation and use of MAKE-MAP:
>>> (define (make-map maker0 setter0 length1 ref1 . more-length&ref-procs)
(do ((length-procs (list length1) (cons (car procs) length-procs))
(ref-procs (list ref1) (cons (cadr procs) ref-procs))
(procs more-length&ref-procs (cddr more-length&ref-procs)))
((null? procs)
(let ((length-procs (reverse length-procs))
(ref-procs (reverse ref-procs)))
(lambda (f x1 . more-args)
(let ((args (cons x1 more-args))
(n (length1 x1)))
(for-each (lambda (length-proc arg)
(if (not (= (length-proc arg) n))
(error "Arguments have different lengths")))
(cdr length-procs)
(cdr args))
(let ((result (maker0 n)))
(do ((i (- n 1) (- i 1)))
((negative? i) result)
(setter0 result i (apply f (map (lambda (ref arg)
(ref arg i))
ref-procs
args)))))))))))
make-map
>>> (define map:string&list->vector
(make-map make-vector vector-set!
string-length string-ref
length list-ref))
map:string&list->vector
>>> (map:string&list->vector list "abcdef" '(0 1 2 3 4 5))
#((#\a 0) (#\b 1) (#\c 2) (#\d 3) (#\e 4) (#\f 5))
This proposal is substantially more general than generic MAP or FOR-EACH
would be (since the length, ref, and setter procedures could perform
arbitrary computations), and could be made equally efficient for the
cases that could be handled by generic MAP and generic FOR-EACH.
Peace, Will
∂12-Jul-89 2216 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #157
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 12 Jul 89 22:16:32 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa29664;
13 Jul 89 0:58 EDT
Date: 13 JUL 89 00:10:56 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #157
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID: <8907130058.aa29664@mintaka.lcs.mit.edu>
Scheme Digest #157 13 JUL 89 00:10:56 EDT
Today's Topics:
DO syntax in XScheme
do loop for 1.6 XScheme
----------------------------------------------------------------------
Date: Wed, 12 Jul 89 16:46:56 GMT
From: NETWORK%FRSAC11.BITNET@mitvma.mit.edu
Subject: DO syntax in XScheme
Message-ID: <8907121059.aa12607@mintaka.lcs.mit.edu>
I am looking deseparatly for a do construct for XSCHEME, 0.15 or 0.16.
The change in macros.s between 0.15 and 0.16 break my
syntax for named-lambda. Any comments or working named-lambda in 0.16 ?
The benchmarks give a noticeable slowdown from 0.15 to 0.16, any comments ?
Any understandable documentation on the macro.s package welcome.
I need the ststuff.c for the atari ST, using MWC, by the way.
I made up something to work with Lattice 3.04, but it may be less than ideal.
Regards,
Jean-Pierre H. Dumas
network@frsac11 (bitnet)
network%frsac11.bitnet@cunyvm.cuny.edu (arpanet)
dumas@sumex-aim.stanford.edu (arpanet)
------------------------------
Date: 12 Jul 89 21:19:40 GMT
From: Shawn McLean <news!mclean@think.com>
Subject: re: do loop for 1.6 XScheme
Message-Id: <MCLEAN.89Jul12171940@pozzo.think.com>
Help yourself. Also included is a defsetf clone. -shawn
;;; (c) Copyright 1989, Shawn Mclean
;;; All rights reserved
;;; Permission is granted for unrestricted non-commercial use
;;; created: Tue 3-28-1989 22:32
;;; XScheme - Version 0.16
;;; commonlisp compatibility macros and functions
;;;
;;; macros
;;;
(macro defmacro
(lambda (form)
(let* ((name (cadr form)) (form (cddr form))
(arglist (car form)) (form (cdr form))
(body (car form)))
(put name '%arglist arglist)
`(macro ,name
(lambda (form)
(apply (lambda ,arglist ,body) (cdr form)))))))
;;;
;;; lists
;;;
(macro first (lambda (form) `(car ,(cadr form))))
(macro second (lambda (form) `(cadr ,(cadr form))))
(macro third (lambda (form) `(caddr ,(cadr form))))
(macro fourth (lambda (form) `(cadddr ,(cadr form))))
(macro fifth (lambda (form) `(caddddr ,(cadr form))))
(macro nth (lambda (form) `(list-ref ,(cadr form) ,(caddr form))))
(macro push
(lambda (form)
(let ((item (cadr form))
(list (caddr form)))
`(set! ,list (cons ,item ,list)))))
(macro pop
(lambda (form)
(let ((list (cadr form))
(item (gensym 'item)))
`(let ((,item (car ,list)))
(set! ,list (cdr ,list))
,item))))
;;;
;;; loops
;;;
(macro do
(lambda (form)
(let (locals test body exits inits updates)
(set! locals (reverse (cadr form)))
(set! form (cddr form))
(set! test (car form))
(set! form (cdr form))
(set! body form)
(set! exits (cdr test))
(set! test (list 'not (car test)))
(while locals
(let* ((local (car locals))
(var (if (list? local) (car local) local))
(init (cadr local))
(update (caddr local)))
(push (list var init) inits)
(if update (push `(set! ,var ,update) updates))
(set! locals (cdr locals))))
`(let ,inits (while ,test ,@body ,@updates) ,@exits))))
(macro do*
(lambda (form)
(let (locals test body exits inits updates)
(set! locals (reverse (cadr form)))
(set! form (cddr form))
(set! test (car form))
(set! form (cdr form))
(set! body form)
(set! exits (cdr test))
(set! test (list 'not (car test)))
(while locals
(let* ((local (car locals))
(var (if (list? local) (car local) local))
(init (cadr local))
(update (caddr local)))
(push (list var init) inits)
(if update (push `(set! ,var ,update) updates))
(set! locals (cdr locals))))
`(let* ,inits (while ,test ,@body ,@updates) ,@exits))))
(macro dotimes
(lambda (form)
(let* ((control (cadr form))
(body (cddr form))
(var (car control))
(limit (cadr control)))
`(let ((,var 0))
(while (< ,var ,limit) ,@body (set! ,var (1+ ,var)))))))
(macro dolist
(lambda (form)
(let* ((control (cadr form))
(body (cddr form))
(item (car control))
(list (cadr control))
(items (gensym 'items)))
`(let ((,items ,list))
(while (not (null? ,items))
(set! ,item (car ,items))
,@body
(set! ,items (cdr ,items)))))))
;;;
;;; debugger
;;;
;;; Is this the way to do this?
(define break
(lambda args
(display "break: ") (dolist (arg (cdr args)) (display arg))
(let ((env (environment-bindings (the-environment))))
(dolist (binding env)
(map display (car binding) ": " (cdr binding))
(newline))
(read))))
;;;
;;; string conversions
;;; not common lisp
(define integer->string
(lambda (integer)
(let ((done nil) (integer-string nil))
(while (not done)
(push (integer->char (+ (char->integer #\0) (remainder integer 10)))
integer-string)
(set! integer (quotient integer 10))
(set! done (= integer 0)))
(list->string integer-string))))
;;;
;;; general accessor
;;;
;;; This is a defsetf clone that works on global functions. A modifier
;;; function is first defined with defset, and following set will invert a
;;; reference. For example:
;;;
;;; (set (car foo) 'bar) => (set-car! foo 'bar)
;;;
;;; If anything, this saves you from typing !'s all over the place. set
;;; will accept one or pairs of auguments.
(macro set
(lambda (pairs)
(if (odd? (length (cdr pairs)))
(error "odd number of arguments to set")
(do* ((place (cdr pairs) (cdr place))
(value (cdr place) (cdr place))
(assignments nil))
((null? place)
(if (cdr assignments)
`(begin ,@(reverse assignments))
(car assignments)))
(set! assignments (cons (general-set (car place) (car value))
assignments))
(set! place (cdr place))))))
(define general-set
(lambda (place value)
(if (list? place)
((get (car place) 'set) (cadr place) value)
`(set! ,place ,value))))
(defmacro defset (function lambda-list values form)
(let ((set-function `(lambda (,@lambda-list ,@values) ,form)))
`(begin (put ',function 'set ,set-function) ',function)))
(defset car (list) (value) `(set-car! ,list ,value))
(defset cdr (list) (value) `(set-cdr! ,list ,value))
------------------------------
End of Scheme Digest
********************
∂13-Jul-89 0537 @mc.lcs.mit.edu,@life.ai.mit.edu:ramsdell@linus.mitre.org fluid variables
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89 05:37:00 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa04407;
13 Jul 89 8:34 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 08:30:46 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa04309;
13 Jul 89 8:28 EDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA02056; Thu, 13 Jul 89 08:28:17 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA22160; Thu, 13 Jul 89 08:24:46 EDT
Posted-Date: Thu, 13 Jul 89 08:24:40 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA02866; Thu, 13 Jul 89 08:24:40 EDT
Date: Thu, 13 Jul 89 08:24:40 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8907131224.AA02866@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
In-Reply-To: will@cs.uoregon.edu's message of Wed, 12 Jul 89 17:05:39 PDT <8907130005.AA17154@spencer.cs.uoregon.edu>
Subject: fluid variables
Reply-To: ramsdell@mitre.org
I support the general idea adding fluid variables to Scheme. We
should face the fact that current-input-port and current-output-port
really should be fluid variables, and define with-input-from-file and
with-output-to-file in terms of fluid-let and call-with-input-file and
call-with-output-file.
I will withdraw my support if implementors feel fluid variables would
slow down their Scheme implementation.
John
∂13-Jul-89 1137 @mc.lcs.mit.edu,@life.ai.mit.edu:mkatz@sesame.stanford.edu last call: changes for R4RS
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89 11:36:52 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa09942;
13 Jul 89 14:14 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 14:08:56 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa09681;
13 Jul 89 14:00 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA00494; Thu, 13 Jul 89 14:00:13 EDT
Received: from life.ai.mit.edu (ai.mit.edu) by zurich.ai.mit.edu; Thu, 13 Jul 89 13:57:13 edt
Received: from sesame.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA05014; Thu, 13 Jul 89 11:57:23 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA27346; Thu, 13 Jul 89 08:56:23 PDT
Date: Thu, 13 Jul 89 08:56:23 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8907131556.AA27346@sesame.Stanford.EDU>
To: will@cs.uoregon.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: will@cs.uoregon.edu's message of Wed, 12 Jul 89 17:03:23 PDT <8907130003.AA17137@spencer.cs.uoregon.edu>
Subject: last call: changes for R4RS
Date: Wed, 12 Jul 89 17:03:23 PDT
From: will@cs.uoregon.edu
Section 6.3.
P1178 has requested again that LIST-REF be made essential, for parallelism
with VECTOR-REF and STRING-REF. Their previous request that LIST-TAIL be
made essential has been dropped.
I have said it beofre, but just to make my position clear, I support the
inclusion of LIST-REF in R4RS if the rest of the proposal for regularization of
sting, vector, and list procedures is adopted; and, I oppose it, otherwise.
Section 6.5.5.
P1178 has requested that MIN and MAX be renamed INF and SUP.
Personally, I prefer the names MIN nad MAX despite the infinum and supremum
semantics. But, I do not feel stonrgly enough about this to put up much of an
argument.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂13-Jul-89 1141 @mc.lcs.mit.edu,@life.ai.mit.edu:mkatz@sesame.stanford.edu Regularization of list, vector, and string procedures
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89 11:41:43 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa10119;
13 Jul 89 14:23 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 14:09:10 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa09685;
13 Jul 89 14:00 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA00497; Thu, 13 Jul 89 14:00:24 EDT
Received: from life.ai.mit.edu (ai.mit.edu) by zurich.ai.mit.edu; Thu, 13 Jul 89 13:57:25 edt
Received: from sesame.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA04957; Thu, 13 Jul 89 11:49:38 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA27294; Thu, 13 Jul 89 08:48:35 PDT
Date: Thu, 13 Jul 89 08:48:35 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8907131548.AA27294@sesame.Stanford.EDU>
To: will@cs.uoregon.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: will@cs.uoregon.edu's message of Wed, 12 Jul 89 17:07:48 PDT <8907130007.AA17164@spencer.cs.uoregon.edu>
Subject: Regularization of list, vector, and string procedures
Date: Wed, 12 Jul 89 17:07:48 PDT
From: will@cs.uoregon.edu
6) String=? is only present for symetry with string-ci=? and should NOT
be generalized to list=? and vector=? since we already have =?.
I think you meant EQUAL? instead of =?.
Correct. RNRS changed between the tie I wrote the initial message (about 1
year ago) and when I reposted it.
1) Create list? which checks for a null terminated list...
This is useful. I prefer the name PROPER-LIST?.
For symetry with STRING? and VECTOR?, I think it should be called LIST? even
though PROPER-LIST? would be a better name in the absence of these
considerations.
2) Generalize apply...[to be generic in the last argument]
I'd prefer to avoid generic procedures at the lowest levels of Scheme.
Why not have LIST-APPLY, VECTOR-APPLY, and STRING-APPLY, by analogy with
LIST-LENGTH, VECTOR-LENGTH, and STRING-LENGTH etc?
I must be suffering from brain damage. This is clearly a better idea and more
in keeping with the spirit of my other recommendations.
3) There are several possibilities for map and foreach:
a) ...
b) Introduce list-map, string-map, vector-map, list-foreach,
string-foreach, and vector-foreach...
c) The same 6 procedures would be introduced as in b). In this
case the name would specify the type of the return value.
The procedures would be polymorphic over arguments of type
list, string, and vector...
In c), it doesn't make sense to have three versions of FOR-EACH distinguished
by the type of their return value, since presumably the return value is
unspecified in each case. Again, I'd prefer type-specific procedures over
generic procedures, because the types are usually known and something like
(VECTOR-FOREACH F V1 V2) conveys more information than (FOREACH F V1 V2).
As a practical matter, the type-specific procedures would have to exist
anyway, and the question is whether the programmer gets to refer to them
directly or must go through a generic interface that obscures the type
information.
The argument in favor of generic procedures is that there would have to be
3 type-specific versions of FOR-EACH and 9 type-specific versions of MAP
even if all the arguments to these procedures are required to be of the
same type. It gets worse if we relax that requirement or if we add more
sequence types.
Here's a counter-proposal: define MAKE-FOREACH and MAKE-MAP that take a
description of the argument and result types for the FOR-EACH or MAP
procedure needed and return the appropriate FOR-EACH or MAP procedure.
Implementations would then be free to special-case these procedures as much
as they feel is necessary, using EQ? tests on the arguments. Sample
implementation and use of MAKE-MAP:
>>> (define (make-map maker0 setter0 length1 ref1 . more-length&ref-procs)
(do ((length-procs (list length1) (cons (car procs) length-procs))
(ref-procs (list ref1) (cons (cadr procs) ref-procs))
(procs more-length&ref-procs (cddr more-length&ref-procs)))
((null? procs)
(let ((length-procs (reverse length-procs))
(ref-procs (reverse ref-procs)))
(lambda (f x1 . more-args)
(let ((args (cons x1 more-args))
(n (length1 x1)))
(for-each (lambda (length-proc arg)
(if (not (= (length-proc arg) n))
(error "Arguments have different lengths")))
(cdr length-procs)
(cdr args))
(let ((result (maker0 n)))
(do ((i (- n 1) (- i 1)))
((negative? i) result)
(setter0 result i (apply f (map (lambda (ref arg)
(ref arg i))
ref-procs
args)))))))))))
make-map
>>> (define map:string&list->vector
(make-map make-vector vector-set!
string-length string-ref
length list-ref))
map:string&list->vector
>>> (map:string&list->vector list "abcdef" '(0 1 2 3 4 5))
#((#\a 0) (#\b 1) (#\c 2) (#\d 3) (#\e 4) (#\f 5))
This proposal is substantially more general than generic MAP or FOR-EACH
would be (since the length, ref, and setter procedures could perform
arbitrary computations), and could be made equally efficient for the
cases that could be handled by generic MAP and generic FOR-EACH.
As I implied in my original message, I did not really like the alternatives I
was presenting. On the other hand, I thing Will's suggestion is a good one.
I, for one, put my stamp of approval on this proposal. Additionally, I would
suggest that MAP and FOREACH remain bound to their current values for backward
compatibility.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂13-Jul-89 1156 @mc.lcs.mit.edu,@life.ai.mit.edu:gls@think.com last call: changes for R4RS
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89 11:56:17 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa10332;
13 Jul 89 14:36 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 14:16:03 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa09175;
13 Jul 89 13:41 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA00297; Thu, 13 Jul 89 13:40:59 EDT
Received: from Think.COM ([131.239.2.1]) by zurich.ai.mit.edu; Thu, 13 Jul 89 13:26:05 edt
Received: from fafnir.think.com by Think.COM; Thu, 13 Jul 89 13:19:49 EDT
Received: from verdi.think.com by fafnir.think.com; Thu, 13 Jul 89 13:18:16 EDT
Received: by verdi.think.com; Thu, 13 Jul 89 13:18:12 EDT
Date: Thu, 13 Jul 89 13:18:12 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8907131718.AA13175@verdi.think.com>
To: will@cs.uoregon.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: will@cs.uoregon.edu's message of Wed, 12 Jul 89 17:03:23 PDT <8907130003.AA17137@spencer.cs.uoregon.edu>
Subject: last call: changes for R4RS
Date: Wed, 12 Jul 89 17:03:23 PDT
From: will@cs.uoregon.edu
...
Section 6.5.5.
P1178 has requested that MIN and MAX be renamed INF and SUP. The rationale
is that the somewhat surprising behavior of MIN and MAX when given mixed
exact and inexact arguments would be more acceptable if their names were
less familiar. A second rationale is that the fact that the mathematical
infimum and supremum operations, when given an infinite set of "arguments",
may return a result that is not in the argument set; this is the surprising
thing about MIN and MAX, e.g. (MAX 1.4 #e1e100) ==> 9.999999999999998e99.
Background: In any case, a note will be added to point out and explain this
behavior, which is required in order for exact results to be trusted. It
happens that MIN and MAX behave this way in Common Lisp as well, although
the motivation was rather different.
I find this proposal quite startling. The objection is that MIN and MAX
don't work properly, and therefore the solution is not to correct their
behavior but to change their names!?
The first rationale is bogus. INF and SUP are standard mathematic
terminology. It is clearly not a question of the terminology as such being
more or less familiar; one can only perhaps say that they are familiar to
fewer people. This is an advantage? Those who do know what INF and SUP are
supposed to mean will only be confused in exactly the same way by the faulty
behavior; those who do not know what they mean are likely to read the
description and then internalize them as "Oh, they are just like MIN and MAX,
only with funny names."
The second rationale is fallacious. Indeed INF (resp. SUP) may return values
not in the set of arguments, but such result is guaranteed to be larger
(resp. smaller) than any of the arguments. The example given fails to have
this property, and renaming MIN and MAX to INF and SUP will not repair the
problem.
Note that Common Lisp does not require MIN and MAX to have faulty
behavior; it merely permits it. When comparing a rational and a float,
MIN and MAX may either apply floating-point contagion and then compare
(leading to possible anomalies), or treat the float as exact and possibly
return the rational, not converted to a float.
The problem is that MIN (or INF) is supposed to return the largest value that
is no smaller than any argument, and currently it fails to do so in Scheme.
So why not just say it that way? Change the definition of MIN and MAX.
Don't give them new names that will have the same problem.
--Guy
∂13-Jul-89 1202 @mc.lcs.mit.edu,@life.ai.mit.edu:Alan@REAGAN.ai.mit.edu legion
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89 12:01:53 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa11183;
13 Jul 89 14:45 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 14:22:39 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa10062;
13 Jul 89 14:21 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA00745; Thu, 13 Jul 89 14:20:57 EDT
Received: from REAGAN.AI.MIT.EDU (reagan.ai.mit.edu) by zurich.ai.mit.edu; Thu, 13 Jul 89 14:17:51 edt
Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 235316; Thu 13-Jul-89 13:38:32 EDT
Date: Thu, 13 Jul 89 13:38 EDT
From: Alan Bawden <Alan@REAGAN.ai.mit.edu>
Subject: legion
To: will@cs.uoregon.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: <8907130005.AA17154@spencer.cs.uoregon.edu>
Message-Id: <19890713173826.2.ALAN@PIGPEN.AI.MIT.EDU>
Date: Wed, 12 Jul 89 17:05:39 PDT
From: will@cs.uoregon.edu
...
Pavel:
...the user cannot portably assign to (or even rebind) variables
named ``if'', ``or'', ``delay'', or even ``unquote''...
...
Jinx:
We've been trying to fix this for quite a while. It has not been
fixed in R4RS because of political and technical problems having to do
with the actual solutions suggested, not because we don't agree that
this should be fixed.
I am not convinced that it should be fixed. So long as the set of
syntactic keywords is very small, keeping them reserved contributes to
readability.
Isn't this an argument against having macros at all? Perhaps you have
always been opposed to macros and I never caught on? Or perhaps I don't
understand your notion of "reserved":
It also appears that the various macro facilities that
have been proposed would be significantly easier to use correctly if
syntactic keywords remain reserved.
I suppose that if by "syntactic keywords remain reserved" you mean that I
am not allowed to introduce any new ones, then indeed all macro facilities
are equally easy to use -- because then you aren't allows to define any
macros at all! Or perhap you draw some kind of distinction between
"syntactic keywords" (that only implementors can create) and "macros" (that
users define)? Like perhaps I am not allowed to shadow IF, while I am
allowed to shadow PUSH (assuming PUSH is a macro that I myself defined)? I
fail to see how this kind of distinction could contribute to anything
except confusion.
In fact, I believe that one of
the main reasons we don't yet have a standard macro facility is that
too much effort has been devoted to the difficulties that arise only
when syntactic keywords can be shadowed by lexical variables.
I completely disagree. I believe that one of the advantages of syntactic
closures is that it solves this problem using exactly the same mechanism it
uses to solve the problems of ordinary lexical variable shadowing. The
"difficulties that arise only when syntactic keywords can be shadowed by
lexical variables" are subdued with no additional "effort" whatsoever.
This issue has nothing to do with why we don't have a standard macro
facility.
∂13-Jul-89 1233 @mc.lcs.mit.edu,@life.ai.mit.edu:gls@think.com Correction
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89 12:33:07 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa12614;
13 Jul 89 15:14 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 15:10:26 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa12295;
13 Jul 89 15:04 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA01670; Thu, 13 Jul 89 15:04:48 EDT
Received: from Think.COM ([131.239.2.1]) by zurich.ai.mit.edu; Thu, 13 Jul 89 15:01:52 edt
Received: from fafnir.think.com by Think.COM; Thu, 13 Jul 89 15:04:46 EDT
Received: from verdi.think.com by fafnir.think.com; Thu, 13 Jul 89 15:03:12 EDT
Received: by verdi.think.com; Thu, 13 Jul 89 15:03:05 EDT
Date: Thu, 13 Jul 89 15:03:05 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8907131903.AA13779@verdi.think.com>
To: gls@think.com
Cc: will@cs.uoregon.edu, rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Guy Steele's message of Thu, 13 Jul 89 13:18:12 EDT <8907131718.AA13175@verdi.think.com>
Subject: Correction
Date: Thu, 13 Jul 89 13:18:12 EDT
From: Guy Steele <gls@Think.COM>
...
The second rationale is fallacious. Indeed INF (resp. SUP) may return values
not in the set of arguments, but such result is guaranteed to be larger
(resp. smaller) than any of the arguments. ...
Sorry--that should have read "smaller (resp. larger)". Editing error.
--Guy
∂13-Jul-89 1238 @mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com Fluid binding
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89 12:38:26 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa12895;
13 Jul 89 15:24 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 15:16:05 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa12538;
13 Jul 89 15:11 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA01893; Thu, 13 Jul 89 15:11:36 EDT
Received: from life.ai.mit.edu (ai.mit.edu) by zurich.ai.mit.edu; Thu, 13 Jul 89 15:08:23 edt
Received: from sde.hp.com (hp-sde.sde.hp.com) by life.ai.mit.edu (4.1/AI-4.10) id AA01156; Thu, 13 Jul 89 05:37:32 EDT
Received: from hpda.HP.COM by hp-sde.sde.hp.com with SMTP
(15.6b/SES42.42) id AA29989; Thu, 13 Jul 89 02:21:05 pdt
Received: from hpesogg (hpesogr) by hpda.HP.COM; Thu, 13 Jul 89 02:21:47 pdt
Message-Id: <8907130921.AA28558@hpda.HP.COM>
Received: by hpesogg; Thu, 13 Jul 89 02:20:39 pdt
Date: Thu, 13 Jul 89 02:20:39 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@hpesogg.hp.com
In-Reply-To: Pavel.pa@xerox.com's message of Wed, 12 Jul 89 11:00:52 PDT
Subject: Fluid binding
Reply-To: jinx%hpda@sde.hp.com
1) MAKE-FLUID, FLUID-REF and FLUID-SET! don't have much to do with
fluids, they have to do with cells (or boxes, as some other people
call them). As such, I would like them to be renamed to
MAKE-CELL, CELL-REF, and CELL-SET!.
Alternatively we could have both MAKE-CELL, CELL-REF, CELL-SET! to
manipulate cells (the selector and mutator always provide the global
value), and FLUID-CELL-REF, FLUID-CELL-SET! to access the current
dynamic value. Which of the accessors is written on top of which
depends on whether the implementation is deep or shallow.
When I first read this, it seemed very reasonable. On later thought,
however, I concluded otherwise. For the first paragraph, I think that,
conceptually, MAKE-FLUID, FLUID-REF and FLUID-SET! have nothing to do with
cells at all. Rather, they traffic in ``fluid variables'', opaque values
that are the domain of the ``fluid environment'' (the range is locations,
just as in the lexical environment). Certainly one implementation of these
procedures (and the one I would use) has MAKE-FLUID return a cell, as you
suggest, but I think renaming them in terms of cells is a convolution of
their abstract semantics with one particular concrete realization.
I think calling these objects fluid "variables" in the context of
other Scheme variables is very misleading. Lexical (ordinary) Scheme
variables can't be aliased, since their addresses cannot be passed
around. These can. Lexical variables can only be affected by special
forms, these can be affected (and usually are) by procedures. Lexical
variables are not first class, they are not even objects since they
are not expressible values. Yours are first class objects. It seems
to me that these fluid variables are much more similar to pairs than
to anything else in the language.
Let's put it another way. In the absence of FLUID-LET, what is the
difference between your fluids and 1-slot records? Your
interpretation is that there is a lot of hair in fluid environments,
etc. Mine is simpler: there are cells, and there is a special form
which establishes a temporary/isolated contents for them. Except for
efficiency, there is no reason why that could not be generalized to
pairs, vectors, etc.
I have additional problems with idea in the second paragraph. In a
shallow-binding implementation, CELL-REF is identical to FLUID-CELL-REF
while in a deep-binding implementation, their semantics is quite different.
I think it unwise for the language semantics to change depending upon a
property of the implementation that should be completely invisible.
The proposal was not completely serious, but you misunderstood it
anyway.
The semantics of these procedures would be the same whether the
implementation was shallow or deep. They would be implemented
differently, and which set was primitive would also vary.
In a shallow implementation, FLUID-CELL-REF and FLUID-CELL-SET! would
be the procedures which merely dereferenced/mutated the cell, and
CELL-REF and CELL-SET! would be implemented on top of them.
In a deep implementation, CELL-REF and CELL-SET! would be the
primitive forms, and the fluid versions would be implemented on top
of them.
In either case, the fluid forms would access/mutate the current fluid
location, while the non-fluid forms would access the global location,
which is not the same as the physical cell. The physical cell could
be accessed/mutated by %CELL-REF and %CELL-SET! which would be one of
the sets, depending on the implementation. I did not suggest adding
the % procedures because they (and only they) are implementation
dependent.
I don't object to this in principle, but I'd rather a somewhat simpler
primitive that doesn't promote lists in this way. For example, the
following:
(fluid-let ((<var-expr1> <val-expr1>)
(<var-expr2> <val-expr2>)
...
(<var-exprN> <val-exprN>))
<body>)
expands into
(let ((var1 <var-expr1>)
(val1 <val-expr1>)
(var2 <var-expr2>)
(val2 <val-expr2>)
...
(varN <var-exprN>)
(valN <val-exprN>)
(body-thunk (lambda () <body>)))
(with-fluid-binding var1 val1
(lambda ()
(with-fluid-binding var2 val2
(lambda ()
...
(with-fluid-binding varN valN
body-thunk) ... )))))
That is, I prefer a primitive that establishes exactly one binding at a
time. Also, since I conceive of this construct in terms of new bindings in
the fluid environment, as opposed to changing the ``contents'' of anything,
a prefer a name for the primitive that says so. Thus my
``with-fluid-binding'' in contrast to Jinx's ``with-cell-contents''.
No problem, except with the name. I was just suggesting that there
should be a basic procedure in terms of which FLUID-LET could be
expanded.
Cedar Scheme is one of those implementations with an incompatible construct
called FLUID-LET, so we would have to rewrite our code as well, but I don't
anticipate it being very hard to do. It seems to me that a very simple
global query-replace could be used to change all of the uses of the old
construct to use a different name. That way, the new standard construct
can use the stylistically correct and appropriate name and old code need
not be rewritten. For example, we might rename our old construct to
SHALLOW-BIND... (Unlike Scheme Xerox, our new implementation, Cedar Scheme
does not support multiple threads of execution.)
Your solution assumes that you can reach all code that used FLUID-LET.
That is unlikely in a wide-spread implementation.
A second objection is purely based on the name. I don't think that
FLUID-LET is a very appropriate name for your form, since it is (in my
mind, where all you are doing is data structure manipulation)
unrelated to LET. I'd much rather have your form be called ISOLATE,
TEMPORARILY, or something like that.
∂13-Jul-89 1446 @mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu last call: changes for R4RS
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89 14:46:20 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa16307;
13 Jul 89 17:22 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 17:04:27 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa15743;
13 Jul 89 17:03 EDT
Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA00499; Thu, 13 Jul 89 17:03:15 EDT
Received: from localhost by zurich.ai.mit.edu; Thu, 13 Jul 89 17:00:18 edt
Date: Thu, 13 Jul 89 17:00:18 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
Message-Id: <8907132100.AA22760@zurich.ai.mit.edu>
To: gls@think.com
Cc: will@cs.uoregon.edu, rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Guy Steele's message of Thu, 13 Jul 89 13:18:12 EDT <8907131718.AA13175@verdi.think.com>
Subject: last call: changes for R4RS
Date: Thu, 13 Jul 89 13:18:12 EDT
From: Guy Steele <gls@think.com>
I find this proposal quite startling. The objection is that MIN and MAX
don't work properly, and therefore the solution is not to correct their
behavior but to change their names!?
[...]
The problem is that MIN (or INF) is supposed to return the largest value that
is no smaller than any argument, and currently it fails to do so in Scheme.
So why not just say it that way? Change the definition of MIN and MAX.
Don't give them new names that will have the same problem.
--Guy
I disagree with the statements in these paragraphs because they
presume a definition of "proper" that I believe is incorrect.
All of this boils down to the meaning of `<', which is very poorly
defined for inexact numbers. Because of this I don't believe that
statements like "don't work properly" and "fails to do so in Scheme"
can be applied here: given a fuzzy definition of `<' on inexact
numbers we are forced to accept a fuzzy definition of "largest" and
"smaller" as well, which further forces us to accept that the result
of `min' will be "correct" (by the definition above) modulo all the
fuzz. This is different from it being correct in a mathematical
sense, but then, that is what the inexactness stuff is all about
anyway.
On the other hand, the above definition will normally hold, except
when inexact numbers are involved AND some implementation limit is
reached, in which case the arithmetic is specifically allowed to
return an inexact number which is mathematically incorrect; then it is
the user's responsibility to deal with the "incorrect" answer.
Perhaps a simpler solution to the whole problem is to add a prominent
warning note, like the one attached to `<' and friends, that warns
about the unreliability of `max' and `min' when inexact numbers are in
use.
∂13-Jul-89 1520 @mc.lcs.mit.edu,@life.ai.mit.edu:gls@think.com last call: changes for R4RS
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89 15:20:08 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa17466;
13 Jul 89 18:11 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 18:06:40 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa17285;
13 Jul 89 18:03 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA01319; Thu, 13 Jul 89 18:03:48 EDT
Received: from Think.COM ([131.239.2.1]) by zurich.ai.mit.edu; Thu, 13 Jul 89 18:00:51 edt
Received: from fafnir.think.com by Think.COM; Thu, 13 Jul 89 18:03:50 EDT
Received: from verdi.think.com by fafnir.think.com; Thu, 13 Jul 89 18:02:12 EDT
Received: by verdi.think.com; Thu, 13 Jul 89 18:02:10 EDT
Date: Thu, 13 Jul 89 18:02:10 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8907132202.AA14486@verdi.think.com>
To: cph@zurich.ai.mit.edu
Cc: gls@think.com, will@cs.uoregon.edu, rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Chris Hanson's message of Thu, 13 Jul 89 17:00:18 edt <8907132100.AA22760@zurich.ai.mit.edu>
Subject: last call: changes for R4RS
Date: Thu, 13 Jul 89 17:00:18 edt
From: cph@zurich.ai.mit.edu (Chris Hanson)
Date: Thu, 13 Jul 89 13:18:12 EDT
From: Guy Steele <gls@think.com>
I find this proposal quite startling. The objection is that MIN and MAX
don't work properly, and therefore the solution is not to correct their
behavior but to change their names!?
[...]
The problem is that MIN (or INF) is supposed to return the largest value that
is no smaller than any argument, and currently it fails to do so in Scheme.
So why not just say it that way? Change the definition of MIN and MAX.
Don't give them new names that will have the same problem.
--Guy
I disagree with the statements in these paragraphs because they
presume a definition of "proper" that I believe is incorrect.
All of this boils down to the meaning of `<', which is very poorly
defined for inexact numbers. Because of this I don't believe that
statements like "don't work properly" and "fails to do so in Scheme"
can be applied here: given a fuzzy definition of `<' on inexact
numbers we are forced to accept a fuzzy definition of "largest" and
"smaller" as well, which further forces us to accept that the result
of `min' will be "correct" (by the definition above) modulo all the
fuzz. This is different from it being correct in a mathematical
sense, but then, that is what the inexactness stuff is all about
anyway.
On the other hand, the above definition will normally hold, except
when inexact numbers are involved AND some implementation limit is
reached, in which case the arithmetic is specifically allowed to
return an inexact number which is mathematically incorrect; then it is
the user's responsibility to deal with the "incorrect" answer.
Perhaps a simpler solution to the whole problem is to add a prominent
warning note, like the one attached to `<' and friends, that warns
about the unreliability of `max' and `min' when inexact numbers are in
use.
Fine. I am happy to agree with everything you say, and your final
suggestion is indeed probably the best solution. The blame can be laid on
<, or on inexactness, if you wish. My main point still stands: WHATEVER
the fundamental difficulty, or wherever you wish to place the blame, simply
renaming the functions to INF and SUP does not solve the problem; the
rationales advanced to support the renaming remain bogus.
--Guy
∂13-Jul-89 1537 @mc.lcs.mit.edu,@LIFE.ai.mit.edu:gjs@hpesogg.hp.com last call: changes for R4RS
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89 15:37:12 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa17712;
13 Jul 89 18:22 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 18:12:24 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa17477;
13 Jul 89 18:11 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA01377; Thu, 13 Jul 89 18:11:20 EDT
Received: from sde.hp.com (sde.hp.com) by zurich.ai.mit.edu; Thu, 13 Jul 89 18:08:22 edt
Received: from hpda.HP.COM by hp-sde.sde.hp.com with SMTP
(15.6b/SES42.42) id AA15414; Thu, 13 Jul 89 15:10:58 pdt
Received: from hpesogg (hpcup18) by hpda.HP.COM; Thu, 13 Jul 89 15:08:35 pdt
Message-Id: <8907132208.AA24978@hpda.HP.COM>
Received: by hpesogg; Thu, 13 Jul 89 15:07:27 pdt
Date: Thu, 13 Jul 89 15:07:27 pdt
From: Gerald Jay Sussman <gjs@hpesogg.hp.com>
To: cph@zurich.ai.mit.edu
Cc: gls@think.com, will@cs.uoregon.edu, rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Chris Hanson's message of Thu, 13 Jul 89 17:00:18 edt <8907132100.AA22760@zurich.ai.mit.edu>
Subject: last call: changes for R4RS
You say:
Perhaps a simpler solution to the whole problem is to add a prominent
warning note, like the one attached to `<' and friends, that warns
about the unreliability of `max' and `min' when inexact numbers are in
use.
I agree with your suggestion completely. It is consistent with
everything else we are doing to do it that way. We don't change the
name of "+" to make it less misleading, we warn about the possible
problems and limitations that appear.
∂13-Jul-89 1622 @mc.lcs.mit.edu,@life.ai.mit.edu:shaff@sesame.stanford.edu last call: changes for R4RS
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89 16:22:02 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa18935;
13 Jul 89 19:16 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 19:13:04 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa18724;
13 Jul 89 19:05 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA01904; Thu, 13 Jul 89 19:05:45 EDT
Received: from sesame.Stanford.EDU (sesame.stanford.edu) by zurich.ai.mit.edu; Thu, 13 Jul 89 19:02:41 edt
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA29641; Thu, 13 Jul 89 16:04:41 PDT
Date: Thu, 13 Jul 89 16:04:41 PDT
From: Mike Shaff <shaff@sesame.stanford.edu>
Message-Id: <8907132304.AA29641@sesame.Stanford.EDU>
To: will@cs.uoregon.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: will@cs.uoregon.edu's message of Wed, 12 Jul 89 17:03:23 PDT <8907130003.AA17137@spencer.cs.uoregon.edu>
Subject: last call: changes for R4RS
ciao,
In the section entitled Procedure calls (4.1.3):
"The operator and operand expressions are evaluated (in an indeterminate order)
and the resulting procedure is passed the resulting arguments."
Is the intention here that the order can be any order as long as it is either
"right-to left" or "left-to-right" or is an implementation truely free to use
any order (which could lead to interleaving on a multi-process implementation)?
(peace chance)
mas
∂13-Jul-89 1635 @mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com Confusion
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89 16:35:04 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa19225;
13 Jul 89 19:26 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 19:13:19 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa18782;
13 Jul 89 19:08 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA01922; Thu, 13 Jul 89 19:08:10 EDT
Received: from sde.hp.com (sde.hp.com) by zurich.ai.mit.edu; Thu, 13 Jul 89 19:05:13 edt
Received: from hpda.HP.COM by hp-sde.sde.hp.com with SMTP
(15.6b/SES42.42) id AA16657; Thu, 13 Jul 89 16:07:40 pdt
Received: from hpesogg (hpesogr) by hpda.HP.COM; Thu, 13 Jul 89 16:05:58 pdt
Message-Id: <8907132305.AA01682@hpda.HP.COM>
Received: by hpesogg; Thu, 13 Jul 89 16:04:39 pdt
Date: Thu, 13 Jul 89 16:04:39 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: willc@cs.uoregon.edu
Cc: gls@think.com, rrrs-authors@hpesogg.hp.com
Subject: Confusion
Reply-To: jinx%hpda@sde.hp.com
I'm confused about a lot of things. Perhaps I should have read Will's
original message more carefully, rather than assume that I knew what
was going on.
P1178 has requested that MIN and MAX be renamed INF and SUP. The rationale
is that the somewhat surprising behavior of MIN and MAX when given mixed
exact and inexact arguments would be more acceptable if their names were
less familiar. A second rationale is that the fact that the mathematical
infimum and supremum operations, when given an infinite set of "arguments",
may return a result that is not in the argument set; this is the surprising
thing about MIN and MAX, e.g. (MAX 1.4 #e1e100) ==> 9.999999999999998e99.
Background: In any case, a note will be added to point out and explain this
behavior, which is required in order for exact results to be trusted. It
happens that MIN and MAX behave this way in Common Lisp as well, although
the motivation was rather different.
As far as I understand it (and GJS agrees with me), the example Will
shows could only be correct in an implementation where
(>= 9.999999999999998e99 #e1e100) is true. If it isn't, the
implementation of MAX/SUP is in error.
If (>= 9.999999999999998e99 #e1e100) holds, then it is not surprising
that MAX/SUP returns 9.999999999999998e99. Perhaps users of such an
implementation should flame at the implementor of >= or of the numeric
printing routine.
The rationale for the renaming these procedures is that MAX and MIN
have a common connotation of returning one of the elements of the
input set. Clearly these procedures don't do this. They are more
like the mathematical definition of SUP and INF which are defined to
return the smallest value >= (or <=) than any of the input parameters.
A different way to look at this is that numbers are not ordered in a
line, but in a lattice. Along the exact and the inexact dimension,
the results are as expected, but when mixing them, we look for the SUP
(INF) in the lattice, so again, the names make sense.
The second rationale is fallacious. Indeed INF (resp. SUP) may return values
not in the set of arguments, but such result is guaranteed to be larger
(resp. smaller) than any of the arguments. The example given fails to have
this property, and renaming MIN and MAX to INF and SUP will not repair the
problem.
The problem is that MIN (or INF) is supposed to return the largest value that
is no smaller than any argument, and currently it fails to do so in Scheme.
So why not just say it that way? Change the definition of MIN and MAX.
Don't give them new names that will have the same problem.
The rationale is not fallacious if you understand that larger or
smaller mean >= and <=, not the expected >= and <= that you compute by
looking at the printed representation. On a good implementation these
two notions of >= should be very close.
If the implementation returns true to the query
(>= 9.999999999999998e99 #e1e100), it is consistent, and is doing what
you expect (modulo it's poor definition of >= or of number->string).
∂13-Jul-89 1721 @mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu last call: changes for R4RS
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89 17:21:02 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa19850;
13 Jul 89 19:47 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 19:39:48 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa19529;
13 Jul 89 19:35 EDT
Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA02199; Thu, 13 Jul 89 19:35:13 EDT
Received: from localhost by zurich.ai.mit.edu; Thu, 13 Jul 89 19:32:16 edt
Date: Thu, 13 Jul 89 19:32:16 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
Message-Id: <8907132332.AA23738@zurich.ai.mit.edu>
To: shaff@sesame.stanford.edu
Cc: will@cs.uoregon.edu, rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Mike Shaff's message of Thu, 13 Jul 89 16:04:41 PDT <8907132304.AA29641@sesame.Stanford.EDU>
Subject: last call: changes for R4RS
Date: Thu, 13 Jul 89 16:04:41 PDT
From: Mike Shaff <shaff@sesame.stanford.edu>
ciao,
In the section entitled Procedure calls (4.1.3):
"The operator and operand expressions are evaluated (in an indeterminate order)
and the resulting procedure is passed the resulting arguments."
Is the intention here that the order can be any order as long as it is either
"right-to left" or "left-to-right" or is an implementation truely free to use
any order (which could lead to interleaving on a multi-process implementation)?
(peace chance)
mas
Certainly the implementation is free to use any SEQUENTIAL order.
It has never been clear to me whether the specification permits
simultaneous evaluation of two different arguments.
∂13-Jul-89 1726 @mc.lcs.mit.edu,@life.ai.mit.edu:shaff@sesame.stanford.edu last call: changes for R4RS
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89 17:25:56 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa20401;
13 Jul 89 19:56 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 19:50:40 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa19803;
13 Jul 89 19:45 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02291; Thu, 13 Jul 89 19:45:08 EDT
Received: from sesame.Stanford.EDU (sesame.stanford.edu) by zurich.ai.mit.edu; Thu, 13 Jul 89 19:42:04 edt
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA29795; Thu, 13 Jul 89 16:43:26 PDT
Date: Thu, 13 Jul 89 16:43:26 PDT
From: Mike Shaff <shaff@sesame.stanford.edu>
Message-Id: <8907132343.AA29795@sesame.Stanford.EDU>
To: jinx%hpda@sde.hp.com
Cc: will@cs.uoregon.edu, rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Guillermo J. Rozas's message of Thu, 13 Jul 89 16:29:25 pdt <8907132333.AA03563@hpda.HP.COM>
Subject: last call: changes for R4RS
ciao,
In an almost immediate response from both Jinx and Chris:
From: Guillermo J. Rozas <jinx@hpesogg.hp.com>
Any sequential order is the intention. Interleaving should not be
allowed because there are no locking primitives to serialize side
effects.
The MIT Scheme compiler chooses an order that it thinks is convenient
for any given combination, but will not interleave the computation
(unless interleaving does not make a difference).
From: cph@zurich.ai.mit.edu (Chris Hanson)
Certainly the implementation is free to use any SEQUENTIAL order.
It has never been clear to me whether the specification permits
simultaneous evaluation of two different arguments.
This being the case (and presuming this is the generally agreed thinking)
shouldn't this choice be made more explicit. I think the absence of said
locking primitives (at the current time) is an issue whose ramifications should
be noted.
(peace chance)
mas
∂13-Jul-89 1734 @mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com Re: evaluation order
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89 17:34:01 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa20762;
13 Jul 89 20:05 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 19:55:58 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa20133;
13 Jul 89 19:54 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02362; Thu, 13 Jul 89 19:54:12 EDT
Received: from Xerox.COM (xerox.com) by zurich.ai.mit.edu; Thu, 13 Jul 89 19:51:13 edt
Received: from Cabernet.ms by ArpaGateway.ms ; 13 JUL 89 16:38:06 PDT
Date: Thu, 13 Jul 89 16:39:54 PDT
From: Pavel.pa@xerox.com
Subject: Re: evaluation order
In-Reply-To: <8907132304.AA29641@sesame.Stanford.EDU>
To: Mike Shaff <shaff@sesame.stanford.edu>
Cc: rrrs-authors@zurich.ai.mit.edu
Message-Id: <890713-163806-2604@Xerox>
I believe the intent is that the operator and operands are evaluated one at
a time in some order. The order need not be either right-to-left or
left-to-right. You can, in some cases, perform the evaluation in parallel,
but the result must be ``serializable'', to steal a term from transaction
systems; that is, the effect must be indistinguishable from some
non-parallel, non-interleaved evaluation.
Pavel
∂13-Jul-89 1747 @mc.lcs.mit.edu,@LIFE.ai.mit.edu:jinx@hpesogg.hp.com last call: changes for R4RS
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89 17:47:28 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa21151;
13 Jul 89 20:20 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 19:34:32 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa19431;
13 Jul 89 19:33 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02185; Thu, 13 Jul 89 19:33:21 EDT
Received: from sde.hp.com (sde.hp.com) by zurich.ai.mit.edu; Thu, 13 Jul 89 19:30:16 edt
Received: from hpda.HP.COM by hp-sde.sde.hp.com with SMTP
(15.6b/SES42.42) id AA17182; Thu, 13 Jul 89 16:32:47 pdt
Received: from hpesogg (hpesogr) by hpda.HP.COM; Thu, 13 Jul 89 16:33:15 pdt
Message-Id: <8907132333.AA03563@hpda.HP.COM>
Received: by hpesogg; Thu, 13 Jul 89 16:29:25 pdt
Date: Thu, 13 Jul 89 16:29:25 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: shaff@sesame.stanford.edu
Cc: will@cs.uoregon.edu, rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Mike Shaff's message of Thu, 13 Jul 89 16:04:41 PDT <8907132304.AA29641@sesame.Stanford.EDU>
Subject: last call: changes for R4RS
Reply-To: jinx%hpda@sde.hp.com
ciao,
In the section entitled Procedure calls (4.1.3):
"The operator and operand expressions are evaluated (in an indeterminate order)
and the resulting procedure is passed the resulting arguments."
Is the intention here that the order can be any order as long as it is either
"right-to left" or "left-to-right" or is an implementation truely free to use
any order (which could lead to interleaving on a multi-process implementation)?
(peace chance)
mas
Any sequential order is the intention. Interleaving should not be
allowed because there are no locking primitives to serialize side
effects.
The MIT Scheme compiler chooses an order that it thinks is convenient
for any given combination, but will not interleave the computation
(unless interleaving does not make a difference).
∂13-Jul-89 1756 @mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@relay.cs.net,@tektronix.tek.com:kend@bloom.la.tek.com Re: last call: changes for R4RS
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89 17:56:30 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa21557;
13 Jul 89 20:39 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 20:35:55 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa21436;
13 Jul 89 20:31 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02735; Thu, 13 Jul 89 20:31:39 EDT
Received: from RELAY.CS.NET (relay.cs.net) by zurich.ai.mit.edu; Thu, 13 Jul 89 20:28:40 edt
Received: from tektronix.tek.com by RELAY.CS.NET id aa10349; 13 Jul 89 18:55 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
id AA28581; Thu, 13 Jul 89 15:57:27 PDT
Received: by dadla.LA.TEK.COM (5.51/6.24)
id AA18298; Thu, 13 Jul 89 15:51:04 PDT
Received: by bloom.LA.TEK.COM (1.2/6.24)
id AA01721; Thu, 13 Jul 89 15:55:52 pdt
Message-Id: <8907132255.AA01721@bloom.LA.TEK.COM>
To: Guy Steele <gls@think.com>
Cc: cph@zurich.ai.mit.edu, will%cs.uoregon.edu@relay.cs.net,
rrrs-authors@zurich.ai.mit.edu
Subject: Re: last call: changes for R4RS
In-Reply-To: Your message of Thu, 13 Jul 89 18:02:10 EDT.
<8907132202.AA14486@verdi.think.com>
Date: 13 Jul 89 15:55:47 PDT (Thu)
From: kend%bloom.la.tek.com@relay.cs.net
Guy says:
.. renaming the functions to INF and SUP does not solve the problem...
The point in the renaming is not to change a suprising behavior, but
to warn that the specified behavior is not in accord with the `simple'
behavior `expected' from MIN and MAX. The IEEE draft expects to cross
reference MAX to SUP and MIN to INF in the index and point out potential
suprises caused by the definitions involved so that a user expecting
algebraic laws to hold is educated to a more refined model with respect to
the realities of machine arithmetic.
-Ken Dickey kend@mrloog.LA.TEK.COM
∂13-Jul-89 1812 @mc.lcs.mit.edu,@life.ai.mit.edu:andy@ads.com Arg evaluation order
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89 18:12:20 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa21742;
13 Jul 89 20:50 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 20:47:01 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa21614;
13 Jul 89 20:42 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02865; Thu, 13 Jul 89 20:42:47 EDT
Received: from hobbes.ads.com ([128.229.32.19]) by zurich.ai.mit.edu; Thu, 13 Jul 89 20:39:48 edt
Received: by hobbes.ads.com (5.59/1.11)
id AA00370; Thu, 13 Jul 89 17:39:34 PDT
Date: Thu, 13 Jul 89 17:39:34 PDT
From: Andy Cromarty <andy@ads.com>
Message-Id: <8907140039.AA00370@hobbes.ads.com>
To: rrrs-authors@zurich.ai.mit.edu
Subject: Arg evaluation order
Cc: andy@ads.com, jinx%hpda@sde.hp.com
MAS writes:
In the section entitled Procedure calls (4.1.3):
"The operator and operand expressions are evaluated (in an
indeterminate order) and the resulting procedure is passed
the resulting arguments."
Is the intention here that the order can be any order as
long as it is either "right-to left" or "left-to-right" or
is an implementation truely free to use any order (which
could lead to interleaving on a multi-process
implementation)?
Jinx replies:
Any sequential order is the intention. Interleaving should not be
allowed because there are no locking primitives to serialize side
effects.
The MIT Scheme compiler chooses an order that it thinks is convenient
for any given combination, but will not interleave the computation
(unless interleaving does not make a difference).
This response surprised and, upon reflection, baffled me sufficiently
to raise me out of my torpor. If we do not specify an evaluation
order, what would be the purpose of requiring sequentiality for
evaluation order? This would seem to have the principal "benefit"
of permitting explicitly nonportable code to be written, in that any
reliance on evaluation order on the part of the programmer is
guaranteed to be implementation-specific.
If evaluation order is desirable, shouldn't we specify it? If it is
undesirable or an area of legitimate experimentation (which position
I favor), shouldn't we leave it entirely unspecified, so that
compiler writers may experiment with it freely? As a programmer, I
might well wish to interleave evaluations in an indeterminate way;
and locking or other appropriate means of achieving serialization
can be imposed by the compiler for the multiprocessor, in those
cases where the programmer "requests" it by using existing
primitives for specifying sequential evaluation. (Note that we
already have constructs that can be used to impose sequentiality,
e.g. to order side-effecting operations--- including at least LAMBDA
bodies, the LET-family bodies, DO bodies, COND, CASE, and BEGIN.)
asc
∂13-Jul-89 1820 @mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com Arg evaluation order
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89 18:20:52 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa21932;
13 Jul 89 21:02 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 20:58:03 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa21811;
13 Jul 89 20:55 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02971; Thu, 13 Jul 89 20:55:11 EDT
Received: from sde.hp.com (sde.hp.com) by zurich.ai.mit.edu; Thu, 13 Jul 89 20:52:14 edt
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.6b/SES42.42) id AA19542; Thu, 13 Jul 89 17:54:49 pdt
Message-Id: <8907140054.AA19542@sde.hp.com>
Received: by hpesogg; Thu, 13 Jul 89 17:53:42 pdt
Date: Thu, 13 Jul 89 17:53:42 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: andy@ads.com
Cc: rrrs-authors@zurich.ai.mit.edu, andy@ads.com
In-Reply-To: Andy Cromarty's message of Thu, 13 Jul 89 17:39:34 PDT <8907140039.AA00370@hobbes.ads.com>
Subject: Arg evaluation order
Reply-To: jinx%hpesogg@sde.hp.com
This response surprised and, upon reflection, baffled me sufficiently
to raise me out of my torpor. If we do not specify an evaluation
order, what would be the purpose of requiring sequentiality for
evaluation order? This would seem to have the principal "benefit"
of permitting explicitly nonportable code to be written, in that any
reliance on evaluation order on the part of the programmer is
guaranteed to be implementation-specific.
If evaluation order is desirable, shouldn't we specify it? If it is
undesirable or an area of legitimate experimentation (which position
I favor), shouldn't we leave it entirely unspecified, so that
compiler writers may experiment with it freely? As a programmer, I
might well wish to interleave evaluations in an indeterminate way;
and locking or other appropriate means of achieving serialization
can be imposed by the compiler for the multiprocessor, in those
cases where the programmer "requests" it by using existing
primitives for specifying sequential evaluation. (Note that we
already have constructs that can be used to impose sequentiality,
e.g. to order side-effecting operations--- including at least LAMBDA
bodies, the LET-family bodies, DO bodies, COND, CASE, and BEGIN.)
The problem is that there are perfectly portable sequential programs
which work when ANY sequential order is used, but not when
interleaved. Consider, for example,
(define (count-nodes! graph-node)
(if (node-marked? graph-node)
0
(begin
(node-mark! graph-node)
(1+ (if (node-leaf? graph-node)
0
(+ (count-nodes! (node-left graph-node))
(count-nodes! (node-right graph-node))))))))
And now think of what happens when a node has the same (eq?) left and
right components, and the arguments to + are interleaved.
∂13-Jul-89 1925 @mc.lcs.mit.edu,@life.ai.mit.edu:andy@ads.com Re: Arg evaluation order
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89 19:25:48 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa23489;
13 Jul 89 22:16 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 22:13:07 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa23305;
13 Jul 89 22:08 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA03672; Thu, 13 Jul 89 22:08:10 EDT
Received: from hobbes.ads.com ([128.229.32.19]) by zurich.ai.mit.edu; Thu, 13 Jul 89 22:05:11 edt
Received: by hobbes.ads.com (5.59/1.11)
id AA00427; Thu, 13 Jul 89 19:06:39 PDT
Date: Thu, 13 Jul 89 19:06:39 PDT
From: Andy Cromarty <andy@ads.com>
Message-Id: <8907140206.AA00427@hobbes.ads.com>
To: jinx%hpesogg@sde.hp.com
Subject: Re: Arg evaluation order
Cc: andy@ads.com, rrrs-authors@zurich.ai.mit.edu
Jinx writes:
The problem is that there are perfectly portable sequential programs
which work when ANY sequential order is used, but not when
interleaved. Consider, for example,
(define (count-nodes! graph-node)
(if (node-marked? graph-node)
0
(begin
(node-mark! graph-node)
(1+ (if (node-leaf? graph-node)
0
(+ (count-nodes! (node-left graph-node))
(count-nodes! (node-right graph-node))))))))
And now think of what happens when a node has the same (eq?) left and
right components, and the arguments to + are interleaved.
So let's see. I infer you are walking a binary cyclic digraph
(otherwise the node-mark! procedure isn't needed), in a
multiprocessor shared-memory environment (otherwise there's no race
condition to resolve). (Knowing this, you might trivially solve
the problem with an atomic test-and-set replacing node-marked? and
node-mark!, but this is cheating, given my suggestion that implicit
serialization should be enough with the compiler generating the
needed serialization code).
Now, a compiler should be able trivially to determine that node-mark!
is a (potential) mutator, and hence that count-nodes! is a mutator;
thus determining that there is a race condition just in case
(eq? (node-left graph-node) (node-right graph-node))
is straightforward, although it's admittedly potentially expensive
for a compiler to test for in general (but that's the compiler-writer's
business, isn't it, and perhaps the compiler executes combinatorically
quickly on the same multiprocessor for which it generates code). Of course,
once the compiler has determined that there is a race condition, there
is nothing to prevent it from generating code that serializes the
evaluation of +'s args---in any order it deems convenient at the
time. It even could produce code that tests the eq?-ness of +'s
args and serializes conditionally; this seems to work, although it
has the weakness that it is combinatorically expensive to test for
race conditions of all left's vs. all right's (needed just in case one
processor executes + faster than another). But a sufficiently "smart"
compiler also might be able to determine when the graph structure in
question is "small" and will not be grown during execution, in which
case the combinatoric cost of completely checking eq?-ness
(especially if it's just once per graph) is uncompelling and concurrent
unserialized execution could be a win in cases where no cells of the graph
are found to be eq?, especially where (say) node-leaf? is a relatively
expensive operation to perform. (This cost-comparison example is somewhat
strained, but then I didn't get to choose the example application. :-)
Note that under the interpretation I proposed, nothing prevents you
from writing a compiler that happens to serialize in whatever order
you find moral, whereas under your intepretation, I might be prohibited
from experimenting with compilers that leave the evaluation order
undefined and make their own decisions about evaluation ordering
dynamically. Also, it is possible (I'm not sure) that your
counterexample begs the question of whether we automatically should
expect "old" sequential code always to run on a shared-memory
multiprocessor without rethinking or redesigning the code.
Apart from the incidental convenience this offers, I'm not sure why
that would be a reasonable expectation, any more than (say) we would
expect IBM/360 assembler code to run on a Sun. Perhaps it's enough to
expect that code written for languages *designed* to execute in both
environments (e.g. FORTRAN-66, for the example of the 360 and Sun) need
no redesign; in my view Scheme presently does not qualify as a language
explicitly designed to work both in uniprocessor and shared-memory
multiprocessor environments. (After all, we still have people advocating
that a construct named WHEN, with all its colloquial intuitive appeal for
capturing time dependency, be [opinion warning:] wasted as syntactic sugar
for IF.)
asc
∂13-Jul-89 2140 @mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com Arg evaluation order
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89 21:40:38 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa27568;
14 Jul 89 0:29 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 14 Jul 89 00:25:00 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa27410;
14 Jul 89 0:18 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA01280; Fri, 14 Jul 89 00:18:40 EDT
Received: from sde.hp.com (sde.hp.com) by zurich.ai.mit.edu; Fri, 14 Jul 89 00:15:44 edt
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.6b/SES42.42) id AA22738; Thu, 13 Jul 89 21:18:23 pdt
Message-Id: <8907140418.AA22738@sde.hp.com>
Received: by hpesogg; Thu, 13 Jul 89 21:17:49 pdt
Date: Thu, 13 Jul 89 21:17:49 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: andy@ads.com
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Andy Cromarty's message of Thu, 13 Jul 89 19:06:39 PDT <8907140206.AA00427@hobbes.ads.com>
Subject: Arg evaluation order
Reply-To: jinx%hpesogg@sde.hp.com
So let's see. I infer you are walking a binary cyclic digraph
(otherwise the node-mark! procedure isn't needed), in a
multiprocessor shared-memory environment (otherwise there's no race
condition to resolve). (Knowing this, you might trivially solve
the problem with an atomic test-and-set replacing node-marked? and
node-mark!, but this is cheating, given my suggestion that implicit
serialization should be enough with the compiler generating the
needed serialization code).
This has nothing to do with parallel processing or race conditions, it
has to do with enforcing the consistency of data structures. If the
language allows interleaved evaluation, there is nothing that prevents
a compiler for a SEQUENTIAL implementation from interleaving the
calls, by open coding, for example, and ignore the interaction between
tests and side effects on "different" branches of the computation.
Now, a compiler should be able trivially to determine that node-mark!
is a (potential) mutator, and hence that count-nodes! is a mutator;
thus determining that there is a race condition just in case
(eq? (node-left graph-node) (node-right graph-node))
is straightforward, although it's admittedly potentially expensive
....
Your argument suffers from two common bugs:
1) The "infinitely smart compiler" bug.
2) Separate compilation (not applicable to my simple example), which means
that the compiler can hardly ever tell anything about side effects
between two operands.
Besides, what are you really arguing? It seems that you are saying
that the current requirement is fine, since a sufficiently smart
compiler will be able to take advantage of interleaving in those cases
where it won't compromise the sematics.
Please, let's make the "infinitely smart compiler" optional, and have
it do a little extra work when it wants to interleave, rather than
allow interleaving in the sequential language, eliminating
predictability.
Note that under the interpretation I proposed, nothing prevents you
from writing a compiler that happens to serialize in whatever order
you find moral, whereas under your intepretation, I might be prohibited
from experimenting with compilers that leave the evaluation order
undefined and make their own decisions about evaluation ordering
dynamically.
That is correct. If you are designing a parallel language, you will
have to specify in which way I can control the evaluation, but that
takes you outside of Scheme. Such a language would NOT be Scheme.
Let's not put everything and the kitchen sink into this language.
∂13-Jul-89 2211 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #158
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89 22:11:13 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa27730;
14 Jul 89 0:39 EDT
Date: 14 JUL 89 00:11:00 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #158
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID: <8907140039.aa27730@mintaka.lcs.mit.edu>
Scheme Digest #158 14 JUL 89 00:11:00 EDT
Today's Topics:
Opening files with Cscheme
----------------------------------------------------------------------
Date: 13 Jul 89 18:36:08 GMT
From: Les Milash <unicads!les@boulder.colorado.edu>
Subject: Opening files with Cscheme
Message-Id: <553@unicads.UUCP>
i have a thing called CScheme, which i love. i have a manual called
RRRS. i have a problem.
i'm trying to write a program that's c-preprocessor compatable, in that
it takes a -I/parameter -I/that/lists/a/bunch -I/of/directories/that
include files might be in. so when the code includes foo.h i have to
find the first one of
/parameter/foo.h
/that/lists/a/bunch/foo.h
/of/directories/that/foo.h
that exists.
RRRS talks about (open-input-file "filename") but if the file doesn't exist
i get an "out of range with "filename"" error and the program stops.
is there a way to figure out if some file exists without crashing? or
some way to substitute some better error behaviour (i'd just as soon
have it return '() or #!the-you-screwed-up-object or something).
i have the CScheme source and am not adverse to making myself un-scheme-
compatable (but i imagine that scheme can do what i want somehow (else
what good is it?))
thanks in advance for the assistance!
Les Milash
wow! with a language like this, i might even be able to handle
a shared-memory multiprocessor!
------------------------------
End of Scheme Digest
********************
∂14-Jul-89 0433 @mc.lcs.mit.edu,@life.ai.mit.edu:gjs@hpesogg.hp.com D. Press, Ing.
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 14 Jul 89 04:33:29 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa04164;
14 Jul 89 7:23 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 14 Jul 89 07:20:29 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa04097;
14 Jul 89 7:15 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA03750; Fri, 14 Jul 89 07:15:51 EDT
Received: from sde.hp.com (sde.hp.com) by zurich.ai.mit.edu; Fri, 14 Jul 89 07:12:54 edt
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.6b/SES42.42) id AA06325; Fri, 14 Jul 89 04:15:32 pdt
Message-Id: <8907141115.AA06325@sde.hp.com>
Received: by hpesogg; Fri, 14 Jul 89 04:14:57 pdt
Date: Fri, 14 Jul 89 04:14:57 pdt
From: Gerald Jay Sussman <gjs@hpesogg.hp.com>
To: rrrs-authors@hpesogg.hp.com
Subject: D. Press, Ing.
A rather exercised character, D. Press, Ing. has been following the
activity of the Scheme mailing list. He has communicated to us the
following commentary on the recent controversies.
GJS & HAL
I'm confused about the unreliability of `max' and `min' when inexact
numbers are not ordered in a line, but in a lattice. Along the exact
and inexact arguments would be more acceptable if their names were
less familiar. A second rationale is that the fact that the
mathematical infimum and supremum operations--- including at least
LAMBDA bodies, the LET-family bodies, DO not specify an indeterminate
order) and the resulting procedure is cheating, given my suggestion
that implicit serialization should be enough with an atomic
test-and-set replacing node-marked? and node-mark! is a (potential)
mutator, and hence that count-nodes! is a mutator; thus determining
that there is convenient for any given combination, but will not
interleave the computation (unless interleaving does not make a
difference).
The point in the renaming is not to change a compiler should be able
trivially to determine that node-mark! is a (potential) mutator, and
now think of what happens when a node has the same (eq?) left" or of
the numeric printing routine.
The rationale is that the somewhat surprising behavior of MIN and MAX
when given mixed exact and inexact arguments would be more acceptable
if their names were less familiar. A second rationale is that the
somewhat surprising behavior of MIN and MAX when given mixed exact and
inexact arguments to + are interleaved.
So let's see. I infer you are walking a common connotation of
returning one of the elements of what happens when a node has the
problem...
A second rationale is that the fact that the mathematical infimum and
supremum operations, when given an infinite set of "arguments", may
return a result that is not in the argument set; this is cheating,
given my suggestion that implicit serialization should be enough with
your suggestion completely. A second rationale is that the fact that
the mathematical infimum and supremum operations, when given an
infinite set of "arguments", may return a result that is not in the
argument set; this is cheating, given my suggestion that implicit
serialization should be enough with your suggestion completely.
"The operator and, upon reflection, baffled me sufficiently to raise
me out of my simple example), which means that the compiler can hardly
ever tell anything about side effects between tests and renaming MIN
and MAX to INF and SUP will not repair the problem is that there are
perfectly portable sequential programs which work when ANY sequential
order is the intention. Interleaving should not be allowed because
there are you really arguing? It seems that you are saying that the
current requirement is fine, since a sufficiently smart compiler will
be able to take advantage of interleaving in those cases where it
won't compromise the sematics.
D. Press, Ing.
∂14-Jul-89 0903 @mc.lcs.mit.edu,@life.ai.mit.edu:shaff@sesame.stanford.edu Released Report
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 14 Jul 89 09:03:22 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa07281;
14 Jul 89 11:58 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 14 Jul 89 11:54:32 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa07215;
14 Jul 89 11:53 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA06100; Fri, 14 Jul 89 11:53:19 EDT
Received: from sesame.Stanford.EDU (sesame.stanford.edu) by zurich.ai.mit.edu; Fri, 14 Jul 89 11:50:17 edt
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA03006; Fri, 14 Jul 89 08:52:29 PDT
Date: Fri, 14 Jul 89 08:52:29 PDT
From: Mike Shaff <shaff@sesame.stanford.edu>
Message-Id: <8907141552.AA03006@sesame.Stanford.EDU>
To: rrrs-authors@zurich.ai.mit.edu
Subject: Released Report
ciao,
Will writes:
I have promised the P1178 editors that I will deliver the final draft of
the R4RS to them by the end of July so they can incorporate it into the
IEEE standard they're drafting. So if you want to influence the R4RS,
you'd better send mail to RRRS-AUTHORS within the next two weeks.
I am definitely in favor of moving forward on issues and getting the report out
to the public, however the latest version of the report that I have (via
zurich) still seems to have some areas that I thought were to be part of the
document (per L&FP such things as macros, name regularization, etc were to be
'rubber stamped' by the group). Is there to be another beta release *before*
the submission to P1178? If not, what happened to those and other favorites?
(peace chance)
mas
∂15-Jul-89 0907 @mc.lcs.mit.edu,@life.ai.mit.edu:shaff@sesame.stanford.edu Released Report
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 15 Jul 89 09:07:36 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa02656;
15 Jul 89 11:51 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 14 Jul 89 11:54:32 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa07215;
14 Jul 89 11:53 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA06100; Fri, 14 Jul 89 11:53:19 EDT
Received: from sesame.Stanford.EDU (sesame.stanford.edu) by zurich.ai.mit.edu; Fri, 14 Jul 89 11:50:17 edt
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA03006; Fri, 14 Jul 89 08:52:29 PDT
Date: Fri, 14 Jul 89 08:52:29 PDT
From: Mike Shaff <shaff@sesame.stanford.edu>
Message-Id: <8907141552.AA03006@sesame.Stanford.EDU>
To: rrrs-authors@zurich.ai.mit.edu
Subject: Released Report
ciao,
Will writes:
I have promised the P1178 editors that I will deliver the final draft of
the R4RS to them by the end of July so they can incorporate it into the
IEEE standard they're drafting. So if you want to influence the R4RS,
you'd better send mail to RRRS-AUTHORS within the next two weeks.
I am definitely in favor of moving forward on issues and getting the report out
to the public, however the latest version of the report that I have (via
zurich) still seems to have some areas that I thought were to be part of the
document (per L&FP such things as macros, name regularization, etc were to be
'rubber stamped' by the group). Is there to be another beta release *before*
the submission to P1178? If not, what happened to those and other favorites?
(peace chance)
mas
∂15-Jul-89 0933 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #159
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 15 Jul 89 09:33:35 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa02876;
15 Jul 89 12:12 EDT
Date: 15 JUL 89 12:01:47 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #159
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID: <8907151212.aa02876@mintaka.lcs.mit.edu>
Scheme Digest #159 15 JUL 89 12:01:47 EDT
Today's Topics:
Opening files with Cscheme
----------------------------------------------------------------------
Date: Fri, 14 Jul 89 10:38:49 edt
From: Chris Hanson <cph@altdorf.ai.mit.edu>
Message-Id: <8907141438.AA01871@altdorf.ai.mit.edu>
Subject: Opening files with Cscheme
Date: 13 Jul 89 18:36:08 GMT
From: Les Milash <unicads!les@boulder.colorado.edu>
i have a thing called CScheme, which i love. i have a manual called
RRRS. i have a problem.
is there a way to figure out if some file exists without crashing?
The procedure `file-exists?' does what you want. It takes a single
argument which is a filename.
------------------------------
End of Scheme Digest
********************
∂15-Jul-89 1102 @mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com Arg evaluation order
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 15 Jul 89 11:02:35 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa03930;
15 Jul 89 13:17 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 15 Jul 89 12:44:32 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa00388;
14 Jul 89 14:44 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA08472; Fri, 14 Jul 89 14:44:38 EDT
Received: from life.ai.mit.edu (ai.mit.edu) by zurich.ai.mit.edu; Fri, 14 Jul 89 14:41:35 edt
Received: from sde.hp.com (hp-sde.sde.hp.com) by life.ai.mit.edu (4.1/AI-4.10) id AA07930; Fri, 14 Jul 89 14:09:18 EDT
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.6b/SES42.42) id AA14308; Fri, 14 Jul 89 11:08:31 pdt
Message-Id: <8907141808.AA14308@sde.hp.com>
Received: by hpesogg; Fri, 14 Jul 89 11:07:53 pdt
Date: Fri, 14 Jul 89 11:07:53 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: sfk@sknight.hpl.hp.com
Cc: andy@ads.com, rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Steve Knight's message of Fri, 14 Jul 89 9:59:35 BST <8907140903.AA18355@otter.hpl.hp.com>
Subject: Arg evaluation order
Reply-To: jinx%hpesogg@sde.hp.com
From: Steve Knight <sfk@sknight.hpl.hp.com>
Date: Fri, 14 Jul 89 9:59:35 BST
X-Mailer: Elm [version 2.0 beta]
> This has nothing to do with parallel processing or race conditions, it
> has to do with enforcing the consistency of data structures.
I agree on this point. Permitting arguments to be evaluated in arbitrary
order makes the compiler writer's life easier at the expense of the language
user. The belief that this compromise is acceptable stems from two sources, I
think.
1. many other languages specify the absence of an evaluation order,
2. the loss of efficiency when evaluation order is specified.
However, this ambiguity gives rise to a distinct class of potential program
defects.
Steve
I think you are confusing two different possibilities here:
1) Not specifying the order of argument evaluation, but requiring
arguments to be evaluated sequentially. Let's call this option
"reordering" of argument evaluation.
2) Allowing interleaving of argument evaluation, ie. evaluate part of
one, then part of another, then part of yet another, then go back to
the first and continue, etc. Let's called this "interleaving" of
argument evaluation.
The current report allows reordering, but not interleaving. Andy was
asking for the language either to pick a particular order or to allow
interleaving.
The main reason for not specifying an order of argument evaluation is
not the loss of efficiency, but rather to discourage programs that
depend on any particular order, since they are at best obscure. Some
of the hardest bugs to find that I have had to deal with arose from
depending on the order of argument evaluation.
Note that current implementations differ in the way they evaluate
their arguments. Most evaluate left to right, but the MIT Scheme
interpreter, for example, evaluates from right to left. Agreeing on a
particular order, besides undesirable, would probably be politically
infeasible at this point.
I also dispute your statement that the compiler writer's job becomes
easier if arguments can be evaluated in any order. It is certainly
easier (although sometimes less efficient) to pick a particular order
and stick to it. Most compilers do this, and they turn out perfectly
efficient code. On the other hand, if the language does not specify
the order of argument evaluation, deciding when reordering is allowed
becomes trivial.
∂15-Jul-89 1210 @mc.lcs.mit.edu,@LIFE.ai.mit.edu:gls@think.com [postmaster@ames.UUCP: Returned mail: User unknown]
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 15 Jul 89 12:10:26 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa04564;
15 Jul 89 14:04 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 15 Jul 89 12:53:15 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa02145;
14 Jul 89 16:54 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA01025; Fri, 14 Jul 89 16:54:55 EDT
Received: from Think.COM ([131.239.2.1]) by zurich.ai.mit.edu; Fri, 14 Jul 89 15:54:44 edt
Received: from fafnir.think.com by Think.COM; Fri, 14 Jul 89 15:57:44 EDT
Received: from verdi.think.com by fafnir.think.com; Fri, 14 Jul 89 15:56:13 EDT
Received: by verdi.think.com; Fri, 14 Jul 89 15:56:12 EDT
Date: Fri, 14 Jul 89 15:56:12 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8907141956.AA19181@verdi.think.com>
To: rrrs-authors@ZURICH.ai.mit.edu
Subject: [postmaster@ames.UUCP: Returned mail: User unknown]
Date: Fri, 14 Jul 89 12:53:30 -0700
From: Mail Delivery Subsystem <postmaster@ames.UUCP>
Subject: Returned mail: User unknown
To: gls@think.UUCP
----- Transcript of session follows -----
550 rrrs-authors... User unknown
----- Unsent message follows -----
Received: by ames.arc.nasa.gov (5.61/1.2); Fri, 14 Jul 89 12:53:30 -0700
Received: from verdi.think.com by news.think.com; Fri, 14 Jul 89 15:53:56 EDT
Received: by verdi.think.com; Fri, 14 Jul 89 15:51:27 EDT
Date: Fri, 14 Jul 89 15:51:27 EDT
>From: think!gls (Guy Steele)
Message-Id: <8907141951.AA19139@verdi.think.com>
To: ames!sde.hp.com!hplabs!jinx%hpda
Cc: willc@cs.uoregon.edu, think!gls, ames!rrrs-authors
In-Reply-To: Guillermo J. Rozas's message of Thu, 13 Jul 89 16:04:39 pdt <8907132305.AA01682@hpda.HP.COM>
Subject: Confusion
Date: Thu, 13 Jul 89 16:04:39 pdt
From: Guillermo J. Rozas <hplabs!hpesogg!jinx@ames.UUCP>
I'm confused about a lot of things. Perhaps I should have read Will's
original message more carefully, rather than assume that I knew what
was going on.
P1178 has requested that MIN and MAX be renamed INF and SUP. The rationale
is that the somewhat surprising behavior of MIN and MAX when given mixed
exact and inexact arguments would be more acceptable if their names were
less familiar. A second rationale is that the fact that the mathematical
infimum and supremum operations, when given an infinite set of "arguments",
may return a result that is not in the argument set; this is the surprising
thing about MIN and MAX, e.g. (MAX 1.4 #e1e100) ==> 9.999999999999998e99.
Background: In any case, a note will be added to point out and explain this
behavior, which is required in order for exact results to be trusted. It
happens that MIN and MAX behave this way in Common Lisp as well, although
the motivation was rather different.
As far as I understand it (and GJS agrees with me), the example Will
shows could only be correct in an implementation where
(>= 9.999999999999998e99 #e1e100) is true. If it isn't, the
implementation of MAX/SUP is in error.
If (>= 9.999999999999998e99 #e1e100) holds, then it is not surprising
that MAX/SUP returns 9.999999999999998e99. Perhaps users of such an
implementation should flame at the implementor of >= or of the numeric
printing routine.
The rationale for the renaming these procedures is that MAX and MIN
have a common connotation of returning one of the elements of the
input set. Clearly these procedures don't do this. They are more
like the mathematical definition of SUP and INF which are defined to
return the smallest value >= (or <=) than any of the input parameters.
A different way to look at this is that numbers are not ordered in a
line, but in a lattice. Along the exact and the inexact dimension,
the results are as expected, but when mixing them, we look for the SUP
(INF) in the lattice, so again, the names make sense.
The second rationale is fallacious. Indeed INF (resp. SUP) may return values
not in the set of arguments, but such result is guaranteed to be larger
(resp. smaller) than any of the arguments. The example given fails to have
this property, and renaming MIN and MAX to INF and SUP will not repair the
problem.
The problem is that MIN (or INF) is supposed to return the largest value that
is no smaller than any argument, and currently it fails to do so in Scheme.
So why not just say it that way? Change the definition of MIN and MAX.
Don't give them new names that will have the same problem.
The rationale is not fallacious if you understand that larger or
smaller mean >= and <=, not the expected >= and <= that you compute by
looking at the printed representation. On a good implementation these
two notions of >= should be very close.
If the implementation returns true to the query
(>= 9.999999999999998e99 #e1e100), it is consistent, and is doing what
you expect (modulo it's poor definition of >= or of number->string).
Thanks you for this exposition. (This is what I get for mouthing
off without having been there, I guess. I was reacting only to the
rationales expressed by Will.)
I now shift my position slightly. I agree that a procedure that computes
(??? 1.4 #e1e100) ==> 9.999999999999998e99 may be useful, and that SUP is a
good name for it. I also believe that a procedure is useful that is
defined to return some one of its arguments such that the returned argument
is >= all other arguments, and that MAX is a good name for that procedure.
(One might also argue that, everything else being equal (!), MAX should
return the least-exact argument having that property, but I won't push that.)
Therefore I argue to include all of SUP, INF, MAX, and MIN.
--Guy
∂15-Jul-89 1217 @mc.lcs.mit.edu:chaynes@iuvax.cs.indiana.edu Minutes of the 3rd IEEE Scheme Working Group meeting
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 15 Jul 89 12:17:20 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa04732;
15 Jul 89 14:18 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 15 Jul 89 12:55:16 EDT
Received: from IUVAX.CS.INDIANA.EDU by mintaka.lcs.mit.edu id aa02609;
14 Jul 89 17:28 EDT
Received: by iuvax.cs.indiana.edu
Date: Fri, 14 Jul 89 16:23:53 -0500
From: Chris Haynes <chaynes@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu, scheme@mc.lcs.mit.edu,
scheme-standard@wheaties.ai.mit.edu
Subject: Minutes of the 3rd IEEE Scheme Working Group meeting
Message-ID: <8907141728.aa02609@mintaka.lcs.mit.edu>
IEEE/MSC/P1178 Working Group on Scheme
Unapproved Minutes of the Third Meeting
7 July 1989
MIT, Cambridge, MA
SUMMARY
R4RS numbers accepted.
Group believes all major technical issues have been resolved in
preparation for submission of draft.
Next meeting at POPL '90.
ACTIONS
The meeting was called to order by Chris Haynes at about 9:45AM. The
following attendance list was collected:
Hal Abelson MIT
Bill Campbell University of Mass at Boston
William Clinger University of Oregon
Ken Dickey Tektronix
Dan Friedman Indiana University
Dick Gabriel Stanford University
Chris Hanson MIT
Chris Haynes Indiana University
Sidney Marshal Xerox
Tim McNerney ILA
James S. Miller Brandeis University
Eric Ost Indiana University
John D. Ramsdell The MITRE Corporation
Guillerimo J. Rozas MIT
Gerald Jay Sussman MIT
Mitchell Wand Northeastern University
1. The agenda was amended; the changes are reflected by the minutes.
2. John D. Ramsdell was elected secretary.
3. Minutes of the second meeting were accepted with no changes.
4. Differences from the last draft.
Chris Hanson described the changes to the draft introduce since the
last meeting.
Changes agreed on at last meeting:
* "User Interface" appendix removed.
* Restore `substring'.
* Delete `with-input-from-port' and `with-output-to-port'.
Changes from R3.95RS:
* Many small editorial changes.
* Characters added to "extended alphabet" set: + - .
* Added number section (pending outcome of third meeting).
* Added description of "implementation error" in support of numbers section.
* New description of:
number->string
string->number
integer->char
char->integer
peek-char
5. Discuss the number section of the standard.
A long discussion followed, which continued until about 2:00PM (with a
lunch break). This resulted in a much wider understanding and
appreciation of the exact/inexact distinction. (In the process it was
clarified that non-numeric operations on numbers, such as storing and
retrieving them, are not allowed to affect their exactness.)
5.1 Moved and accepted: The editors will change wording in section
1.3.1 to clarify the notion of an implementation error.
Specific directions include, dropping the word "arbitrary" in
paragraph 3 and changing the following two sentences to read something
like: "When an implementation error is reported, the report must make
clear that an implementation restriction was violated. Implementation
restrictions are of course discouraged, but reporting their violation
is encouraged."
5.2 Moved and unanimously accepted: We accept the number section of
R4RS with some editorial changes.
5.3 Moved and accepted: We recommend that the R4RS authors rename the
procedure max to sup, and procedure min to inf.
5.4 Moved and rejected: If R4RS does not change the names of max and
min, P1178 should eliminate max and min.
5.5 Moved and accepted: Add expt to the list of procedures which
must return an exact result when given exact arguments (section 6.5.3).
5.6 Moved and accepted: Add an example showing the use of explicit
coercion of an inexact argument as an index of vector-ref.
5.7 Moved and unanimously accepted: The editors will add to the body
of the text the requirement that implementations must support a
minimal subset of numeric procedures and request that the R4RS authors
change the status to essential of any unessential procedure required
to support the minimal subset.
It was noted that the proscriptive wording (e.g., "shall", "must") in
appendix B.3) should be softened (e.g., "should").
The editors reaffirmed their intention to substantially extend
appendix B.3, including, for instance, a discussion of the
transitivity requirements for the numeric order and equality predicates.
6. R4RS status report
Will Clinger described the changes he expected between R3.95RS and
R4RS. He promised a R3.99RS (R4RS without macro appendices) within a
month.
* Add ... as a <peculiar identifier>.
* Change the branch cuts of some trig functions to be like Common Lisp's.
* Make char->integer and integer->char one-to-one.
* Return char-upper-case? to R4RS, which was dropped due to an editing error.
* Leave it unspecified as to whether the empty list counts as false.
* Change number->string description.
7. Moved and accepted: We request that the R4RS authors add a
sentence encouraging that implementations support an international
character set, most likely ISO Latin 1 (ISO8859-1).
8. A move that ":" be change to not be an extended alphanumeric
character was not seconded.
9. Moved and accepted: We request that the R4RS authors consider
making just list-ref (and not list-tail) essential.
10. A move to discuss changing the semantics of internal definitions was
not seconded.
11. Moved and accepted: It is suggested that the next meeting of the
IEEE Scheme Working Group be on January 19, 1989, following the
Principles of Programming Languages conference in San Francisco, CA.
There was general consensus that at the next meeting the Working Group
could probably approve the draft standard for submission to the MSC
for public comment and balloting. Therefore the draft to be
considered at the next meeting should be mailed to all those on the
Working Group mailing list no later than mid-November.
12. Moved and unanimously accepted: The draft standard distributed at
the meeting (reflecting the changes detailed under item 4 above)
should be submitted to ISO WG-16 for consideration, with a brief
cover statement to be drafted by Chris Haynes.
Dick Gabriel reported that ANSII asked X3J13 whether Scheme and Common
Lisp were distinct enough to justify two standards. Bob Mathis
provided technical arguments convincing ANSII that they were distinct.
Meeting adjourned at about 3:30PM.
-- Minutes by John D. Ramsdell, edited by Chris Haynes
∂15-Jul-89 1323 @mc.lcs.mit.edu,@life.ai.mit.edu:shaff@sesame.stanford.edu Force & Delay manual reorganization
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 15 Jul 89 13:23:04 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa05784;
15 Jul 89 15:37 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 15 Jul 89 15:03:08 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa04281;
14 Jul 89 19:25 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA00232; Fri, 14 Jul 89 19:25:40 EDT
Received: from sesame.Stanford.EDU (sesame.stanford.edu) by zurich.ai.mit.edu; Fri, 14 Jul 89 19:22:40 edt
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA04729; Fri, 14 Jul 89 16:24:54 PDT
Date: Fri, 14 Jul 89 16:24:54 PDT
From: Mike Shaff <shaff@sesame.stanford.edu>
Message-Id: <8907142324.AA04729@sesame.Stanford.EDU>
To: rrrs-authors@zurich.ai.mit.edu
Subject: Force & Delay manual reorganization
ciao,
Force and delay are currently in totally separate sections of R3.95RS which can
lead readers to hours of fun and enjoyment. Perhaps the Delayed Evaluation
section (4.2.5) can be made a subsection of Control Features (6.9) and expanded
to include force.
(peace chance)
mas
∂15-Jul-89 1328 @mc.lcs.mit.edu,@life.ai.mit.edu:shaff@sesame.stanford.edu Distinct types for continuations?
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 15 Jul 89 13:28:48 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa05915;
15 Jul 89 15:49 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 15 Jul 89 15:03:27 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa04423;
14 Jul 89 19:40 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA00358; Fri, 14 Jul 89 19:40:32 EDT
Received: from sesame.Stanford.EDU (sesame.stanford.edu) by zurich.ai.mit.edu; Fri, 14 Jul 89 19:37:30 edt
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA04796; Fri, 14 Jul 89 16:39:43 PDT
Date: Fri, 14 Jul 89 16:39:43 PDT
From: Mike Shaff <shaff@sesame.stanford.edu>
Message-Id: <8907142339.AA04796@sesame.Stanford.EDU>
To: rrrs-authors@zurich.ai.mit.edu
Subject: Distinct types for continuations?
ciao,
It seems to us that continuations and procedures should be considered distinct
types. With this in mind we propose the inclusion of a new procedure in R4RS
named continuation? that has the obvious semantics. The procedure procedure?
would, of course, need to be changed such that it would return #f if given a
continuation. This only seems consistent with the decision at L&FP '88 to make
characters and numbers distinct types.
(peace chance)
mas & Morry Katz
∂15-Jul-89 2255 @mc.lcs.mit.edu,@LIFE.ai.mit.edu:shaff@sesame.stanford.edu Arg evaluation order
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 15 Jul 89 22:55:26 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa12851;
16 Jul 89 0:35 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 16 Jul 89 00:31:28 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa12635;
16 Jul 89 0:23 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA10027; Sun, 16 Jul 89 00:23:26 EDT
Received: from sesame.Stanford.EDU (sesame.stanford.edu) by zurich.ai.mit.edu; Sun, 16 Jul 89 00:20:15 edt
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA08066; Sat, 15 Jul 89 11:32:27 PDT
Date: Sat, 15 Jul 89 11:32:27 PDT
From: Mike Shaff <shaff@sesame.stanford.edu>
Message-Id: <8907151832.AA08066@sesame.Stanford.EDU>
To: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: "Guillermo J. Rozas"'s message of Fri, 14 Jul 89 11:07:53 pdt <8907141808.AA14308@sde.hp.com>
Subject: Arg evaluation order
ciao,
Jinx writes:
1) Not specifying the order of argument evaluation, but requiring
arguments to be evaluated sequentially. Let's call this option
"reordering" of argument evaluation.
2) Allowing interleaving of argument evaluation, ie. evaluate part of
one, then part of another, then part of yet another, then go back to
the first and continue, etc. Let's called this "interleaving" of
argument evaluation.
The current report allows reordering, but not interleaving.
I have not been advocating a change in the semantics that I think most people
agree is intended by the report, rather a clarification (or greater
specificity) in the language regarding this issue.
(peace chance)
mas
∂15-Jul-89 2315 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #160
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 15 Jul 89 23:15:44 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa13421;
16 Jul 89 1:10 EDT
Date: 16 JUL 89 00:01:54 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #160
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID: <8907160110.aa13421@mintaka.lcs.mit.edu>
Scheme Digest #160 16 JUL 89 00:01:54 EDT
Today's Topics:
Opening files with Cscheme
Minutes of the 3rd IEEE Scheme Working Group meeting
----------------------------------------------------------------------
Date: 14 Jul 89 17:53:22 GMT
From: unicads!les@boulder.colorado.edu (Les Milash)
Subject: Re: Opening files with Cscheme
Message-Id: <557@unicads.UUCP>
thanks, everyhody, for telling me about the function `file-exists?'.
you can stop now :-) you've been overwhelmingly helpful.
ya know, i've never gotten more code working faster than with this
wierd Scheme stuff! i guess that's what it's all about, huh?
------------------------------
Date: Fri, 14 Jul 89 16:23:53 -0500
From: Chris Haynes <chaynes@iuvax.cs.indiana.edu>
Subject: Minutes of the 3rd IEEE Scheme Working Group meeting
Message-ID: <8907141728.aa02609@mintaka.lcs.mit.edu>
IEEE/MSC/P1178 Working Group on Scheme
Unapproved Minutes of the Third Meeting
7 July 1989
MIT, Cambridge, MA
SUMMARY
R4RS numbers accepted.
Group believes all major technical issues have been resolved in
preparation for submission of draft.
Next meeting at POPL '90.
ACTIONS
The meeting was called to order by Chris Haynes at about 9:45AM. The
following attendance list was collected:
Hal Abelson MIT
Bill Campbell University of Mass at Boston
William Clinger University of Oregon
Ken Dickey Tektronix
Dan Friedman Indiana University
Dick Gabriel Stanford University
Chris Hanson MIT
Chris Haynes Indiana University
Sidney Marshal Xerox
Tim McNerney ILA
James S. Miller Brandeis University
Eric Ost Indiana University
John D. Ramsdell The MITRE Corporation
Guillerimo J. Rozas MIT
Gerald Jay Sussman MIT
Mitchell Wand Northeastern University
1. The agenda was amended; the changes are reflected by the minutes.
2. John D. Ramsdell was elected secretary.
3. Minutes of the second meeting were accepted with no changes.
4. Differences from the last draft.
Chris Hanson described the changes to the draft introduce since the
last meeting.
Changes agreed on at last meeting:
* "User Interface" appendix removed.
* Restore `substring'.
* Delete `with-input-from-port' and `with-output-to-port'.
Changes from R3.95RS:
* Many small editorial changes.
* Characters added to "extended alphabet" set: + - .
* Added number section (pending outcome of third meeting).
* Added description of "implementation error" in support of numbers section.
* New description of:
number->string
string->number
integer->char
char->integer
peek-char
5. Discuss the number section of the standard.
A long discussion followed, which continued until about 2:00PM (with a
lunch break). This resulted in a much wider understanding and
appreciation of the exact/inexact distinction. (In the process it was
clarified that non-numeric operations on numbers, such as storing and
retrieving them, are not allowed to affect their exactness.)
5.1 Moved and accepted: The editors will change wording in section
1.3.1 to clarify the notion of an implementation error.
Specific directions include, dropping the word "arbitrary" in
paragraph 3 and changing the following two sentences to read something
like: "When an implementation error is reported, the report must make
clear that an implementation restriction was violated. Implementation
restrictions are of course discouraged, but reporting their violation
is encouraged."
5.2 Moved and unanimously accepted: We accept the number section of
R4RS with some editorial changes.
5.3 Moved and accepted: We recommend that the R4RS authors rename the
procedure max to sup, and procedure min to inf.
5.4 Moved and rejected: If R4RS does not change the names of max and
min, P1178 should eliminate max and min.
5.5 Moved and accepted: Add expt to the list of procedures which
must return an exact result when given exact arguments (section 6.5.3).
5.6 Moved and accepted: Add an example showing the use of explicit
coercion of an inexact argument as an index of vector-ref.
5.7 Moved and unanimously accepted: The editors will add to the body
of the text the requirement that implementations must support a
minimal subset of numeric procedures and request that the R4RS authors
change the status to essential of any unessential procedure required
to support the minimal subset.
It was noted that the proscriptive wording (e.g., "shall", "must") in
appendix B.3) should be softened (e.g., "should").
The editors reaffirmed their intention to substantially extend
appendix B.3, including, for instance, a discussion of the
transitivity requirements for the numeric order and equality predicates.
6. R4RS status report
Will Clinger described the changes he expected between R3.95RS and
R4RS. He promised a R3.99RS (R4RS without macro appendices) within a
month.
* Add ... as a <peculiar identifier>.
* Change the branch cuts of some trig functions to be like Common Lisp's.
* Make char->integer and integer->char one-to-one.
* Return char-upper-case? to R4RS, which was dropped due to an editing error.
* Leave it unspecified as to whether the empty list counts as false.
* Change number->string description.
7. Moved and accepted: We request that the R4RS authors add a
sentence encouraging that implementations support an international
character set, most likely ISO Latin 1 (ISO8859-1).
8. A move that ":" be change to not be an extended alphanumeric
character was not seconded.
9. Moved and accepted: We request that the R4RS authors consider
making just list-ref (and not list-tail) essential.
10. A move to discuss changing the semantics of internal definitions was
not seconded.
11. Moved and accepted: It is suggested that the next meeting of the
IEEE Scheme Working Group be on January 19, 1989, following the
Principles of Programming Languages conference in San Francisco, CA.
There was general consensus that at the next meeting the Working Group
could probably approve the draft standard for submission to the MSC
for public comment and balloting. Therefore the draft to be
considered at the next meeting should be mailed to all those on the
Working Group mailing list no later than mid-November.
12. Moved and unanimously accepted: The draft standard distributed at
the meeting (reflecting the changes detailed under item 4 above)
should be submitted to ISO WG-16 for consideration, with a brief
cover statement to be drafted by Chris Haynes.
Dick Gabriel reported that ANSII asked X3J13 whether Scheme and Common
Lisp were distinct enough to justify two standards. Bob Mathis
provided technical arguments convincing ANSII that they were distinct.
Meeting adjourned at about 3:30PM.
-- Minutes by John D. Ramsdell, edited by Chris Haynes
------------------------------
End of Scheme Digest
********************
∂16-Jul-89 1000 @mc.lcs.mit.edu,@decwrl.dec.com:jmiller@crl.dec.com [Scheme-Request@mc.lcs.mit.edu: Scheme Digest #158]
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 16 Jul 89 10:00:17 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa00739;
16 Jul 89 11:05 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 15 Jul 89 12:55:30 EDT
Received: from decwrl.dec.com by mintaka.lcs.mit.edu id aa02848;
14 Jul 89 17:46 EDT
Received: from crl.crl.dec.com by decwrl.dec.com (5.54.5/4.7.34)
id AA28239; Fri, 14 Jul 89 09:24:31 PDT
Received: from crl.crl.dec.com by decwrl.dec.com (5.54.5/4.7.34)
for rrrs-authors@mc.lcs.mit.edu; id AA28239; Fri, 14 Jul 89 09:24:31 PDT
Received: by crl.crl.dec.com (5.57/Ultrix2.4-C)
id AA05497; Fri, 14 Jul 89 09:42:05 EDT
Date: Fri, 14 Jul 89 09:43:04 EDT
From: jmiller@crl.dec.com
Message-Id: <8907141343.AA02131@peanut.DEC.COM>
To: rrrs-authors@mc.lcs.mit.edu
Subject: [Scheme-Request@mc.lcs.mit.edu: Scheme Digest #158]
Reply-To: JMiller@crl.enet.dec.com
For anyone how hasn't seen it, here's an independent message that
serves to emphasize my argument in favor of Ken Dickey's suggestion
that OPEN-[IN/OUT]PUT-FILE should allow some way of avoiding the
signalled error. The problem is real, not just hypothetical as you
can see from an honest-to-goodness USER of the language.
The message was sent to Scheme@mc.lcs.mit.edu. I editted it for this
transmission.
--Jim
Date: 13 Jul 89 18:36:08 GMT
From: Les Milash <unicads!les@boulder.colorado.edu>
i have a manual called RRRS. i have a problem.
i'm trying to write a program that's c-preprocessor compatable, in that
it takes a -I/parameter -I/that/lists/a/bunch -I/of/directories/that
include files might be in. so when the code includes foo.h i have to
find the first one of
/parameter/foo.h
/that/lists/a/bunch/foo.h
/of/directories/that/foo.h
that exists.
RRRS talks about (open-input-file "filename") but if the file doesn't exist
i get an "out of range with "filename"" error and the program stops.
is there a way to figure out if some file exists without crashing? or
some way to substitute some better error behaviour (i'd just as soon
have it return '() or #!the-you-screwed-up-object or something).
i have the CScheme source and am not adverse to making myself un-scheme-
compatable (but i imagine that scheme can do what i want somehow (else
what good is it?))
∂16-Jul-89 1341 @mc.lcs.mit.edu,@life.ai.mit.edu:danvy@freja.diku.dk Re: Distinct types for continuations?
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 16 Jul 89 13:41:00 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa04312;
16 Jul 89 16:29 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 16 Jul 89 16:26:24 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa04243;
16 Jul 89 16:22 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA13763; Sun, 16 Jul 89 16:20:46 EDT
Received: from freja.diku.dk ([129.142.96.1]) by zurich.ai.mit.edu; Sun, 16 Jul 89 16:17:32 edt
Received: by freja.diku.dk
(5.61++/IDA-1.2.8) id AA15278; Sun, 16 Jul 89 17:06:06 +0200
Date: Sun, 16 Jul 89 17:06:06 +0200
From: Olivier Danvy <danvy@diku.dk>
Message-Id: <8907161506.AA15278@freja.diku.dk>
To: rrrs-authors@zurich.ai.mit.edu, shaff@sesame.stanford.edu
Subject: Re: Distinct types for continuations?
A problem in distinguishing procedures and continuations
is the one of eta-redexes.
We would have
(call-with-current-continuation continuation?) -> #t
(call-with-current-continuation procedure?) -> #f
and
(call-with-current-continuation
(lambda (k)
(continuation? k))) -> #t
but
(call-with-current-continuation
(lambda (k)
(continuation? (lambda (v)
(k v))))) -> #f
In other terms, do we want to distinguish k and (lambda (v) (k v))?
Or to introduce some operator "throw" or "continue"?
A motivation for representing first-class continuations as procedures
is that procedures can be defined as continuation transformers:
Cont = Val -> Ans
Proc = Cont -> Val -> Ans = Cont -> Cont
Then it is possible to present first-class continuations
as procedures that substitute the continuations that were reified
for the current continuation.
Peace as well, Olivier
∂16-Jul-89 2144 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #161
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 16 Jul 89 21:44:07 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa09261;
17 Jul 89 0:32 EDT
Date: 17 JUL 89 00:01:56 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #161
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID: <8907170032.aa09261@mintaka.lcs.mit.edu>
Scheme Digest #161 17 JUL 89 00:01:56 EDT
Today's Topics:
Xscheme object context diffs & sample (425 lines)
The defintion of TRUE and FALSE in Scheme.
----------------------------------------------------------------------
Date: 16 Jul 89 14:12:44 GMT
From: David W Crabb <phoenix!crabb@princeton.edu>
Subject: Xscheme object context diffs & sample (425 lines)
Message-Id: <9447@phoenix.Princeton.EDU>
Since, as far as I know, no solution to the bad behavior of the objects
in Xscheme has yet appeared here, I am posting one.
Two files are appended to this posting:
xschemen.dif
tryit.xs
The former consists of context diffs for the program PATCH . These must be
compiled in order to make the object/class capability of Xscheme, vers. 0.16,
work in a manner similar to Xlisp (especially the versions of Xlisp prior to
the introduction of "send").
The second file is for trying out some of those capabilities, and is
designed to illustrate how close the modification comes to implementing
what was presumably the original design idea.
Note that very few lines of code need to be added or modified:
xscomn.c 1 line added
xsintn.c 3 lines added 1 line deleted
xsobjn.c 8 lines added 4 lines deleted 4 lines modified
---------------- xschemen.dif ----------------------------------------
*** xscom.c Thu Jul 13 14:50:58 1989
--- xscomn.c Thu Jul 13 15:19:04 1989
***************
*** 1,3
/* xscom.c - a simple scheme bytecode compiler */
/* Copyright (c) 1988, by David Michael Betz
All Rights Reserved
--- 1,8 -----
+ /** modified xlfunction
+ David W. Crabb (crabb@phoenix.princeton.edu)
+ July, 1989
+ **/
+
/* xscom.c - a simple scheme bytecode compiler */
/* Copyright (c) 1988, by David Michael Betz
All Rights Reserved
***************
*** 101,107
return (pop());
}
! /* xlfunction - compile a function */
LVAL xlfunction(fun,fargs,body,ctenv)
LVAL fun,fargs,body,ctenv;
{
--- 106,112 -----
return (pop());
}
! /* xlfunction - compile a function */ /* used only by clanswer() **/
LVAL xlfunction(fun,fargs,body,ctenv)
LVAL fun,fargs,body,ctenv;
{
***************
*** 110,115
rplaca(info,newframe(ctenv,1));
rplacd(info,cons(NIL,NIL));
/* setup the base of the code for this function */
cbase = cptr = 0;
--- 115,122 -----
rplaca(info,newframe(ctenv,1));
rplacd(info,cons(NIL,NIL));
+ rplacd (car(info), ctenv); /** DWC: 7/5/89 */
+
/* setup the base of the code for this function */
cbase = cptr = 0;
***************
*** 316,322
/* initialize the argument name list and slot number */
restarg = last = NIL;
slotn = 1;
!
/* handle each required argument */
while (consp(fargs) && (arg = car(fargs)) && !lambdakey(arg)) {
--- 323,329 -----
/* initialize the argument name list and slot number */
restarg = last = NIL;
slotn = 1;
!
/* handle each required argument */
while (consp(fargs) && (arg = car(fargs)) && !lambdakey(arg)) {
*** xsint.c Thu Jul 13 14:50:59 1989
--- xsintn.c Thu Jul 13 14:50:59 1989
***************
*** 1,3
/* xsint.c - xscheme bytecode interpreter */
/* Copyright (c) 1988, by David Michael Betz
All Rights Reserved
--- 1,8 -----
+ /** modified METHOD case of xlapply()
+ David W. Crabb (crabb@phoenix.princeton.edu)
+ July, 1989
+ **/
+
/* xsint.c - xscheme bytecode interpreter */
/* Copyright (c) 1988, by David Michael Betz
All Rights Reserved
***************
*** 6,11
#include "xscheme.h"
#include "xsbcode.h"
/* sample rate (instructions per sample) */
#define SRATE 1000
--- 11,19 -----
#include "xscheme.h"
#include "xsbcode.h"
+ /** from xsobj.c : */
+ #define IVENV 1
+
/* sample rate (instructions per sample) */
#define SRATE 1000
***************
*** 356,362
break;
case METHOD:
xlfun = getcode(xlval);
! xlenv = cons(top(),getenv(xlval));
base = pc = getcodestr(xlfun);
break;
case CONTINUATION:
--- 364,374 -----
break;
case METHOD:
xlfun = getcode(xlval);
!
! xlenv = getenv(xlval); /** DWC 7/5/89 */
! tmp = getivar(top(),IVENV); /** DWC 7/11 */
! rplacd(xlenv, tmp);
!
base = pc = getcodestr(xlfun);
break;
case CONTINUATION:
*** xsobj.c Thu Jul 13 14:50:59 1989
--- xsobjn.c Thu Jul 13 15:10:12 1989
***************
*** 1,3
/* xsobj.c - xscheme object-oriented programming support */
/* Copyright (c) 1988, by David Michael Betz
All Rights Reserved
--- 1,8 -----
+ /** Modifications to clanswer(), clisnew(), and clnew() .
+ David W. Crabb (crabb@phoenix.princeton.edu)
+ July, 1989
+ **/
+
/* xsobj.c - xscheme object-oriented programming support */
/* Copyright (c) 1988, by David Michael Betz
All Rights Reserved
***************
*** 13,18
static LVAL s_self,k_isnew;
static LVAL class,object;
/* instance variable numbers for the class 'Class' */
#define MESSAGES 1 /* list of messages */
#define IVARS 2 /* list of instance variable names */
--- 18,28 -----
static LVAL s_self,k_isnew;
static LVAL class,object;
+ /** DWC: instance variable numbers for objects */
+ #define IVENV 1 /** ivars now passed as an environment */
+ /** number of instance variables for objects */
+ #define IVTOT 2
+
/* instance variable numbers for the class 'Class' */
#define MESSAGES 1 /* list of messages */
#define IVARS 2 /* list of instance variable names */
***************
*** 140,146
/* clnew - create a new object instance */
clnew()
{
! LVAL self;
/* create a new object */
self = xlgaobject();
--- 150,157 -----
/* clnew - create a new object instance */
clnew()
{
! int i;
! LVAL self, ivframe,ivars,c ;
/* create a new object */
self = xlgaobject();
***************
*** 144,150
/* create a new object */
self = xlgaobject();
! xlval = newobject(self,getivcnt(self,IVARTOTAL));
/* send the 'isnew' message */
xlsend(xlval,k_isnew);
--- 155,161 -----
/* create a new object */
self = xlgaobject();
! xlval = newobject(self,IVTOT);
ivars = getivar(self,IVARS);
ivframe = newframe(NIL,listlength(ivars) + 1);
***************
*** 146,151
self = xlgaobject();
xlval = newobject(self,getivcnt(self,IVARTOTAL));
/* send the 'isnew' message */
xlsend(xlval,k_isnew);
}
--- 157,167 -----
self = xlgaobject();
xlval = newobject(self,IVTOT);
+ ivars = getivar(self,IVARS);
+ ivframe = newframe(NIL,listlength(ivars) + 1);
+ setelement(car(ivframe),0,ivars);
+ setivar(xlval,IVENV, ivframe);
+
/* send the 'isnew' message */
xlsend(xlval,k_isnew);
}
***************
*** 153,159
/* clisnew - initialize a new class */
LVAL clisnew()
{
! LVAL self,ivars,cvars,super;
int n;
/* get self, the ivars, cvars and superclass */
--- 169,175 -----
/* clisnew - initialize a new class */
LVAL clisnew()
{
! LVAL self,ivars,cvars,super, tmp;
int n;
/* get self, the ivars, cvars and superclass */
***************
*** 163,172
super = (moreargs() ? xlgaobject() : object);
xllastarg();
- /* create the class variable compile-time environment */
- xlval = cons(xlenter("%%CLASS"),copylists(cvars,NIL));
- cpush(cons(xlval,getivar(super,CVARS)));
-
/* create the class variable environment */
xlval = newvector(listlength(xlval)); setelement(xlval,0,self);
cpush(cons(xlval,getivar(super,CVALS)));
--- 179,184 -----
super = (moreargs() ? xlgaobject() : object);
xllastarg();
/* create the class variable environment */
xlval = newvector(listlength(xlval)); setelement(xlval,0,self);
cpush(cons(xlval,getivar(super,CVALS)));
***************
*** 172,178
cpush(cons(xlval,getivar(super,CVALS)));
/* store the instance and class variable lists and the superclass */
! setivar(self,IVARS,copylists(getivar(super,IVARS),ivars));
setivar(self,CVALS,pop());
setivar(self,CVARS,pop());
setivar(self,SUPERCLASS,super);
--- 184,191 -----
cpush(cons(xlval,getivar(super,CVALS)));
/* store the instance and class variable lists and the superclass */
! setivar(self,IVARS,ivars); /* to be retrieved in clnew() **/
!
setivar(self,CVALS,pop());
tmp = newframe(NIL,listlength(cvars) + 1);
***************
*** 174,180
/* store the instance and class variable lists and the superclass */
setivar(self,IVARS,copylists(getivar(super,IVARS),ivars));
setivar(self,CVALS,pop());
! setivar(self,CVARS,pop());
setivar(self,SUPERCLASS,super);
/* compute the instance variable count */
--- 187,197 -----
setivar(self,IVARS,ivars); /* to be retrieved in clnew() **/
setivar(self,CVALS,pop());
!
! tmp = newframe(NIL,listlength(cvars) + 1);
! setelement(car(tmp),0,cvars);
! setivar(self,CVARS,tmp);
!
setivar(self,SUPERCLASS,super);
/* compute the instance variable count */
***************
*** 191,197
LVAL clanswer()
{
extern LVAL xlfunction();
! LVAL self,msg,fargs,code,mptr;
/* message symbol, formal argument list and code */
self = xlgaobject();
--- 208,214 -----
LVAL clanswer()
{
extern LVAL xlfunction();
! LVAL self,msg,fargs,code,mptr, tmp;
/* message symbol, formal argument list and code */
self = xlgaobject();
***************
*** 206,214
/* add 'self' to the argument list */
cpush(cons(s_self,fargs));
! /* extend the class variable environment with the instance variables */
! xlval = cons(getivar(self,IVARS),getivar(self,CVARS));
!
/* compile and store the method */
xlval = xlfunction(msg,top(),code,xlval);
rplacd(mptr,cvmethod(xlval,getivar(self,CVALS)));
--- 223,230 -----
/* add 'self' to the argument list */
cpush(cons(s_self,fargs));
! tmp = getivar (self,CVARS) ; /** now an env from clisnew() */
!
/* compile and store the method */
xlval = xlfunction(msg,top(),code,tmp);
rplacd(mptr,cvmethod(xlval, tmp));
***************
*** 210,217
xlval = cons(getivar(self,IVARS),getivar(self,CVARS));
/* compile and store the method */
! xlval = xlfunction(msg,top(),code,xlval);
! rplacd(mptr,cvmethod(xlval,getivar(self,CVALS)));
drop(1);
/* return the object */
--- 226,233 -----
tmp = getivar (self,CVARS) ; /** now an env from clisnew() */
/* compile and store the method */
! xlval = xlfunction(msg,top(),code,tmp);
! rplacd(mptr,cvmethod(xlval, tmp));
drop(1);
/* return the object */
----------------------- tryit.xs ------------------------------------
; "tryit.xs" for loading into xscheme - modified version .
; David W. Crabb crabb@phoenix.princeton.edu
(define aClass (Class 'new '(ivar1 ivar2) '(cvar1 cvar2)))
(define anInst (aClass 'new))
(aClass 'answer 'set-cvar1 '(value) '( (set! cvar1 value)))
(aClass 'answer 'cvar1? '() '( (print cvar1)))
(aClass 'show)
(anInst 'set-cvar1 592)
(anInst 'cvar1?) ; >> 592
(aClass 'answer 'set-ivar1 '() '( (set! ivar1 5505)))
(anInst 'set-ivar1)
(aClass 'answer 'ivar1? '() '( (print ivar1)))
(anInst 'ivar1?) ; >> 5505
(define subClass (Class 'new '(ivar1 ivar2) '(cvar1 cvar2) aClass ))
(define subInst (subClass 'new))
(subInst 'cvar1?) ; >> 592
(subInst 'ivar1?) ; >> ()
(aClass 'answer 'reset-ivar1 '() '( (set! ivar1 -66)))
(subInst 'reset-ivar1) (subInst 'ivar1?) ; >> -66
(anInst 'ivar1?) ; >> 5505
;; -------------------- eof ----------------------------------------------
------------------------------
Date: 16 Jul 89 04:18:26 GMT
From: "Mario O. Bourgoin" <mob@media-lab.media.mit.edu>
Subject: The defintion of TRUE and FALSE in Scheme.
Message-Id: <152@mit-amt.MEDIA.MIT.EDU>
I've been wanting to replace the usual LISP definitions of TRUE and
FALSE by functions because that seems more in the spirit of Scheme.
Furthermore, with functions we can eliminate ``if'' and ``cond'' from
the essential syntax of Scheme which simplifies the analysis of
extensions to Scheme such as Zabih, McAllester, and Chapman's
non-deterministic operator, ``amb''. I would like to get the Scheme
community's reaction to the specification of particular objects for
TRUE and FALSE, namely the functions:
(define true (lambda (iftrue iffalse) iftrue))
(define false (lambda (iftrue iffalse) iffalse))
Naturally, the constants #t and #f would always denote the appropriate
one of these two functions.
Given the above definitions for TRUE and FALSE, ``if'' statements can
be replaced according to the following pattern:
(if predicate iftrue iffalse) =>
((predicate (lambda () iftrue) (lambda () iffalse)))
And ``cond'' may be replaced thus:
(cond (predicate1 body1)
(predicate2 body2)
(predicate3 body3)
(else bodyelse))
becomes:
((predicate1
(lambda () body1)
(lambda ()
((predicate2
(lambda () body2)
(lambda ()
((predicate3
(lambda () body3)
(lambda () bodyelse)))))))))
The logical connectives ``not'', ``and'', and ``or'' could be defined
as follows.
(not predicate) => (predicate false true)
(or predicate1 predicate2) => (predicate1 true predicate2)
(and predicate1 predicate2) => (predicate1 predicate2 false)
Naturally, the definitions for ``or'' and ``and'' can be extended to
handle a variable number of parameters.
Please tell me of any problems you see with such a definition.
--Mario O. Bourgoin
------------------------------
End of Scheme Digest
********************
∂17-Jul-89 0910 @mc.lcs.mit.edu,@gateway.think.com:gls@think.com [gls@Think.COM: [postmaster@ames.UUCP: Returned mail: User unknown]]
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 17 Jul 89 09:09:59 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa16229;
17 Jul 89 12:00 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 17 Jul 89 11:54:51 EDT
Received: from Gateway.Think.COM by mintaka.lcs.mit.edu id aa16079;
17 Jul 89 11:49 EDT
Received: from fafnir.think.com by Think.COM; Mon, 17 Jul 89 11:49:22 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Mon, 17 Jul 89 11:47:41 EDT
Received: by verdi.think.com; Mon, 17 Jul 89 11:47:39 EDT
Date: Mon, 17 Jul 89 11:47:39 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8907171547.AA24575@verdi.think.com>
To: rrrs-authors@mc.lcs.mit.edu, rrrs-authors@life.ai.mit.edu
Subject: [gls@Think.COM: [postmaster@ames.UUCP: Returned mail: User unknown]]
I apologize to those who receive multiple copies of this. The mailers
seem to be a bit confused.
--Guy
Date: Fri, 14 Jul 89 15:56:12 EDT
From: Guy Steele <gls@Think.COM>
To: rrrs-authors@zurich.ai.mit.edu
Subject: [postmaster@ames.UUCP: Returned mail: User unknown]
Date: Fri, 14 Jul 89 12:53:30 -0700
>From: Mail Delivery Subsystem <postmaster@ames.UUCP>
Subject: Returned mail: User unknown
To: gls@think.UUCP
----- Transcript of session follows -----
550 rrrs-authors... User unknown
----- Unsent message follows -----
Received: by ames.arc.nasa.gov (5.61/1.2); Fri, 14 Jul 89 12:53:30 -0700
Received: from verdi.think.com by news.think.com; Fri, 14 Jul 89 15:53:56 EDT
Received: by verdi.think.com; Fri, 14 Jul 89 15:51:27 EDT
Date: Fri, 14 Jul 89 15:51:27 EDT
>From: think!gls (Guy Steele)
Message-Id: <8907141951.AA19139@verdi.think.com>
To: ames!sde.hp.com!hplabs!jinx%hpda
Cc: willc@cs.uoregon.edu, think!gls, ames!rrrs-authors
In-Reply-To: Guillermo J. Rozas's message of Thu, 13 Jul 89 16:04:39 pdt <8907132305.AA01682@hpda.HP.COM>
Subject: Confusion
Date: Thu, 13 Jul 89 16:04:39 pdt
From: Guillermo J. Rozas <hplabs!hpesogg!jinx@ames.UUCP>
I'm confused about a lot of things. Perhaps I should have read Will's
original message more carefully, rather than assume that I knew what
was going on.
P1178 has requested that MIN and MAX be renamed INF and SUP. The rationale
is that the somewhat surprising behavior of MIN and MAX when given mixed
exact and inexact arguments would be more acceptable if their names were
less familiar. A second rationale is that the fact that the mathematical
infimum and supremum operations, when given an infinite set of "arguments",
may return a result that is not in the argument set; this is the surprising
thing about MIN and MAX, e.g. (MAX 1.4 #e1e100) ==> 9.999999999999998e99.
Background: In any case, a note will be added to point out and explain this
behavior, which is required in order for exact results to be trusted. It
happens that MIN and MAX behave this way in Common Lisp as well, although
the motivation was rather different.
As far as I understand it (and GJS agrees with me), the example Will
shows could only be correct in an implementation where
(>= 9.999999999999998e99 #e1e100) is true. If it isn't, the
implementation of MAX/SUP is in error.
If (>= 9.999999999999998e99 #e1e100) holds, then it is not surprising
that MAX/SUP returns 9.999999999999998e99. Perhaps users of such an
implementation should flame at the implementor of >= or of the numeric
printing routine.
The rationale for the renaming these procedures is that MAX and MIN
have a common connotation of returning one of the elements of the
input set. Clearly these procedures don't do this. They are more
like the mathematical definition of SUP and INF which are defined to
return the smallest value >= (or <=) than any of the input parameters.
A different way to look at this is that numbers are not ordered in a
line, but in a lattice. Along the exact and the inexact dimension,
the results are as expected, but when mixing them, we look for the SUP
(INF) in the lattice, so again, the names make sense.
The second rationale is fallacious. Indeed INF (resp. SUP) may return values
not in the set of arguments, but such result is guaranteed to be larger
(resp. smaller) than any of the arguments. The example given fails to have
this property, and renaming MIN and MAX to INF and SUP will not repair the
problem.
The problem is that MIN (or INF) is supposed to return the largest value that
is no smaller than any argument, and currently it fails to do so in Scheme.
So why not just say it that way? Change the definition of MIN and MAX.
Don't give them new names that will have the same problem.
The rationale is not fallacious if you understand that larger or
smaller mean >= and <=, not the expected >= and <= that you compute by
looking at the printed representation. On a good implementation these
two notions of >= should be very close.
If the implementation returns true to the query
(>= 9.999999999999998e99 #e1e100), it is consistent, and is doing what
you expect (modulo it's poor definition of >= or of number->string).
Thanks you for this exposition. (This is what I get for mouthing
off without having been there, I guess. I was reacting only to the
rationales expressed by Will.)
I now shift my position slightly. I agree that a procedure that computes
(??? 1.4 #e1e100) ==> 9.999999999999998e99 may be useful, and that SUP is a
good name for it. I also believe that a procedure is useful that is
defined to return some one of its arguments such that the returned argument
is >= all other arguments, and that MAX is a good name for that procedure.
(One might also argue that, everything else being equal (!), MAX should
return the least-exact argument having that property, but I won't push that.)
Therefore I argue to include all of SUP, INF, MAX, and MIN.
--Guy
∂17-Jul-89 1059 @mc.lcs.mit.edu,@life.ai.mit.edu:gls@think.com [gls@Think.COM: [postmaster@ames.UUCP: Returned mail: User unknown]]
Received: from lcs.mit.edu (XX.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 17 Jul 89 10:58:53 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa16409;
17 Jul 89 12:09 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 17 Jul 89 11:55:04 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa16080;
17 Jul 89 11:49 EDT
Received: from Think.COM (Gateway.Think.COM) by life.ai.mit.edu (4.1/AI-4.10) id AA00664; Mon, 17 Jul 89 11:49:05 EDT
Received: from fafnir.think.com by Think.COM; Mon, 17 Jul 89 11:49:22 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Mon, 17 Jul 89 11:47:41 EDT
Received: by verdi.think.com; Mon, 17 Jul 89 11:47:39 EDT
Date: Mon, 17 Jul 89 11:47:39 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8907171547.AA24575@verdi.think.com>
To: rrrs-authors@mc.lcs.mit.edu, rrrs-authors@life.ai.mit.edu
Subject: [gls@Think.COM: [postmaster@ames.UUCP: Returned mail: User unknown]]
I apologize to those who receive multiple copies of this. The mailers
seem to be a bit confused.
--Guy
Date: Fri, 14 Jul 89 15:56:12 EDT
From: Guy Steele <gls@Think.COM>
To: rrrs-authors@zurich.ai.mit.edu
Subject: [postmaster@ames.UUCP: Returned mail: User unknown]
Date: Fri, 14 Jul 89 12:53:30 -0700
>From: Mail Delivery Subsystem <postmaster@ames.UUCP>
Subject: Returned mail: User unknown
To: gls@think.UUCP
----- Transcript of session follows -----
550 rrrs-authors... User unknown
----- Unsent message follows -----
Received: by ames.arc.nasa.gov (5.61/1.2); Fri, 14 Jul 89 12:53:30 -0700
Received: from verdi.think.com by news.think.com; Fri, 14 Jul 89 15:53:56 EDT
Received: by verdi.think.com; Fri, 14 Jul 89 15:51:27 EDT
Date: Fri, 14 Jul 89 15:51:27 EDT
>From: think!gls (Guy Steele)
Message-Id: <8907141951.AA19139@verdi.think.com>
To: ames!sde.hp.com!hplabs!jinx%hpda
Cc: willc@cs.uoregon.edu, think!gls, ames!rrrs-authors
In-Reply-To: Guillermo J. Rozas's message of Thu, 13 Jul 89 16:04:39 pdt <8907132305.AA01682@hpda.HP.COM>
Subject: Confusion
Date: Thu, 13 Jul 89 16:04:39 pdt
From: Guillermo J. Rozas <hplabs!hpesogg!jinx@ames.UUCP>
I'm confused about a lot of things. Perhaps I should have read Will's
original message more carefully, rather than assume that I knew what
was going on.
P1178 has requested that MIN and MAX be renamed INF and SUP. The rationale
is that the somewhat surprising behavior of MIN and MAX when given mixed
exact and inexact arguments would be more acceptable if their names were
less familiar. A second rationale is that the fact that the mathematical
infimum and supremum operations, when given an infinite set of "arguments",
may return a result that is not in the argument set; this is the surprising
thing about MIN and MAX, e.g. (MAX 1.4 #e1e100) ==> 9.999999999999998e99.
Background: In any case, a note will be added to point out and explain this
behavior, which is required in order for exact results to be trusted. It
happens that MIN and MAX behave this way in Common Lisp as well, although
the motivation was rather different.
As far as I understand it (and GJS agrees with me), the example Will
shows could only be correct in an implementation where
(>= 9.999999999999998e99 #e1e100) is true. If it isn't, the
implementation of MAX/SUP is in error.
If (>= 9.999999999999998e99 #e1e100) holds, then it is not surprising
that MAX/SUP returns 9.999999999999998e99. Perhaps users of such an
implementation should flame at the implementor of >= or of the numeric
printing routine.
The rationale for the renaming these procedures is that MAX and MIN
have a common connotation of returning one of the elements of the
input set. Clearly these procedures don't do this. They are more
like the mathematical definition of SUP and INF which are defined to
return the smallest value >= (or <=) than any of the input parameters.
A different way to look at this is that numbers are not ordered in a
line, but in a lattice. Along the exact and the inexact dimension,
the results are as expected, but when mixing them, we look for the SUP
(INF) in the lattice, so again, the names make sense.
The second rationale is fallacious. Indeed INF (resp. SUP) may return values
not in the set of arguments, but such result is guaranteed to be larger
(resp. smaller) than any of the arguments. The example given fails to have
this property, and renaming MIN and MAX to INF and SUP will not repair the
problem.
The problem is that MIN (or INF) is supposed to return the largest value that
is no smaller than any argument, and currently it fails to do so in Scheme.
So why not just say it that way? Change the definition of MIN and MAX.
Don't give them new names that will have the same problem.
The rationale is not fallacious if you understand that larger or
smaller mean >= and <=, not the expected >= and <= that you compute by
looking at the printed representation. On a good implementation these
two notions of >= should be very close.
If the implementation returns true to the query
(>= 9.999999999999998e99 #e1e100), it is consistent, and is doing what
you expect (modulo it's poor definition of >= or of number->string).
Thanks you for this exposition. (This is what I get for mouthing
off without having been there, I guess. I was reacting only to the
rationales expressed by Will.)
I now shift my position slightly. I agree that a procedure that computes
(??? 1.4 #e1e100) ==> 9.999999999999998e99 may be useful, and that SUP is a
good name for it. I also believe that a procedure is useful that is
defined to return some one of its arguments such that the returned argument
is >= all other arguments, and that MAX is a good name for that procedure.
(One might also argue that, everything else being equal (!), MAX should
return the least-exact argument having that property, but I won't push that.)
Therefore I argue to include all of SUP, INF, MAX, and MIN.
--Guy
∂17-Jul-89 1337 @mc.lcs.mit.edu,@life.ai.mit.edu:shaff@sesame.stanford.edu Distinct types for continuations?
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 17 Jul 89 13:37:32 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa19418;
17 Jul 89 16:30 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 17 Jul 89 16:27:14 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa19335;
17 Jul 89 16:23 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA03828; Mon, 17 Jul 89 16:22:43 EDT
Received: from sesame.Stanford.EDU (sesame.stanford.edu) by zurich.ai.mit.edu; Mon, 17 Jul 89 16:19:29 edt
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA16188; Mon, 17 Jul 89 09:52:43 PDT
Date: Mon, 17 Jul 89 09:52:43 PDT
From: Mike Shaff <shaff@sesame.stanford.edu>
Message-Id: <8907171652.AA16188@sesame.Stanford.EDU>
To: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Olivier Danvy's message of Sun, 16 Jul 89 17:06:06 +0200 <8907161506.AA15278@freja.diku.dk>
Subject: Distinct types for continuations?
ciao,
According to our reading of Will's denotational semantics for R3.95RS,
continuations and procedures of one argument are in different semantic domains.
This seems to add credence to our desire to be able to distinguish between
continuations and procedures. If it is indeed decided that continuations and
their eta converted versions [e.g., (lambda (v) (k v))] should be
indistinguishable then the denotational semantics should be updated to reflect
this similarity.
(peace chance)
mas & Morry
∂17-Jul-89 1443 @mc.lcs.mit.edu:Alan@REAGAN.ai.mit.edu Numbers
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 17 Jul 89 14:43:40 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa20283;
17 Jul 89 17:34 EDT
Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by MC.LCS.MIT.EDU 17 Jul 89 17:30:20 EDT
Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 237020; Mon 17-Jul-89 17:29:57 EDT
Date: Mon, 17 Jul 89 17:29 EDT
From: Alan Bawden <Alan@REAGAN.ai.mit.edu>
Subject: Numbers
To: gls@think.com, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: <8907171547.AA24575@verdi.think.com>,
<8907141728.aa02609@mintaka.lcs.mit.edu>,
<8907132208.AA24978@hpda.HP.COM>
Message-ID: <19890717212952.6.ALAN@PIGPEN.AI.MIT.EDU>
Date: Fri, 14 Jul 89 15:51:27 EDT
From: think!gls (Guy Steele)
Subject: Confusion
I now shift my position slightly. I agree that a procedure that computes
(??? 1.4 #e1e100) ==> 9.999999999999998e99 may be useful, and that SUP is a
good name for it. I also believe that a procedure is useful that is
defined to return some one of its arguments such that the returned argument
is >= all other arguments, and that MAX is a good name for that procedure.
(One might also argue that, everything else being equal (!), MAX should
return the least-exact argument having that property, but I won't push that.)
Therefore I argue to include all of SUP, INF, MAX, and MIN.
--Guy
Except MAX and MIN have a bug with respect to the notion of exactness.
They return an exact answer when they are not entitled to. And they have
the good names, so programmers will use them and nobody will use INF and
SUP. Doing this is a subtle way of degrading the concept of an exact
number.
Date: Thu, 13 Jul 89 15:07:27 pdt
From: Gerald Jay Sussman <gjs@hpesogg.hp.com>
You say:
Perhaps a simpler solution to the whole problem is to add a prominent
warning note, like the one attached to `<' and friends, that warns
about the unreliability of `max' and `min' when inexact numbers are in
use.
I agree with your suggestion completely. It is consistent with
everything else we are doing to do it that way. We don't change the
name of "+" to make it less misleading, we warn about the possible
problems and limitations that appear.
Indeed, if we do this, then MIN and MAX are unreliable in the same way that
the numeric predicates are. They will be the only numeric -functions- that
require such a warning. INF and SUP require no such warning.
If we really aren't going to take exactness seriously, then I would rather
not have it at all. If we -are- going to take exactness seriously, then we
should flush "unreliable" MIN and MAX, and change the names of INF and SUP
back to MIN and MAX. INF and SUP are the correct Scheme representation for
the mathematical functions in question, given the principles of exactness.
From the Unapproved Minutes of the Third Meeting of the IEEE Working Group
on Scheme:
5.5 Moved and accepted: Add expt to the list of procedures which
must return an exact result when given exact arguments (section 6.5.3).
Does this mean that (expt 2 50) -must- return an exact number? Suppose I
have an implementation with 32 bit FIXNUMs as my exact numbers, IEEE
FLONUMs as my inexact numbers, but no BIGNUMs. Am I forbidden from
returning a FLONUM (inexact) answer, even though my FLONUMs have the range?
Does this mean that (expt 2 50) would have to signal an error, even though
(* (expt 2 25) (expt 2 25)) would be allowed to return a FLONUM (inexact)
answer?
The editors reaffirmed their intention to substantially extend
appendix B.3, including, for instance, a discussion of the
transitivity requirements for the numeric order and equality predicates.
This should be fun. Once you start letting people take their naive notions
of how numbers should behave and turn them into -requirements-, all hell
can break lose. On what basis do you decide that the order predicates are
required to be transitive, but that + is not required to be associative?
The danger is that requirements may be adopted just in case people can
imagine a way to meet them in an implementation that uses floating point
for its inexact numbers. Unless some restraint is exercised, this can
eliminate plausible implementations of inexact numbers that aren't floating
point.
∂17-Jul-89 1517 @mc.lcs.mit.edu,@life.ai.mit.edu:Alan@REAGAN.ai.mit.edu Distinct types for continuations?
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 17 Jul 89 15:17:26 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa20669;
17 Jul 89 18:00 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 17 Jul 89 17:56:36 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa20499;
17 Jul 89 17:47 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA04965; Mon, 17 Jul 89 17:47:02 EDT
Received: from REAGAN.AI.MIT.EDU (reagan.ai.mit.edu) by zurich.ai.mit.edu; Mon, 17 Jul 89 17:43:56 edt
Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 237034; Mon 17-Jul-89 17:46:53 EDT
Date: Mon, 17 Jul 89 17:46 EDT
From: Alan Bawden <Alan@REAGAN.ai.mit.edu>
Subject: Distinct types for continuations?
To: shaff@sesame.stanford.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: <8907171652.AA16188@sesame.Stanford.EDU>
Message-Id: <19890717214647.7.ALAN@PIGPEN.AI.MIT.EDU>
Date: Mon, 17 Jul 89 09:52:43 PDT
From: Mike Shaff <shaff@sesame.stanford.edu>
According to our reading of Will's denotational semantics for R3.95RS,
continuations and procedures of one argument are in different semantic domains.
This seems to add credence to our desire to be able to distinguish between
continuations and procedures. If it is indeed decided that continuations and
their eta converted versions [e.g., (lambda (v) (k v))] should be
indistinguishable then the denotational semantics should be updated to reflect
this similarity.
Assuming that the denotational semantics hasn't changed drastically since
R3RS, this is false. The objects in the continuation domain are not handed
directly to users, and they would not function correctly if they were. If
you will look at the definition of CALL-WITH-CURRENT-CONTINUATION I think
you will find that it carefully constructs an appropriate object from the
domain of procedures. (Perhaps the name should be changed to
"CALL-WITH-PROCEDURE-CONTAINING-CURRENT-CONTINUATION".) If we decide that
the objects created by CALL-WITH-CURRENT-CONTINUATION -are- distinguishable
from procedures, only then will it be necessary to change the denotational
semantics.
∂17-Jul-89 1533 @mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu Numbers
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 17 Jul 89 15:33:31 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa20859;
17 Jul 89 18:12 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 17 Jul 89 18:08:13 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa20761;
17 Jul 89 18:05 EDT
Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA05320; Mon, 17 Jul 89 18:05:26 EDT
Received: from localhost by zurich.ai.mit.edu; Mon, 17 Jul 89 18:02:17 edt
Date: Mon, 17 Jul 89 18:02:17 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
Message-Id: <8907172202.AA10010@zurich.ai.mit.edu>
To: Alan@REAGAN.ai.mit.edu
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Alan Bawden's message of Mon, 17 Jul 89 17:29 EDT <19890717212952.6.ALAN@PIGPEN.AI.MIT.EDU>
Subject: Numbers
Date: Mon, 17 Jul 89 17:29 EDT
From: Alan Bawden <Alan@REAGAN.ai.mit.edu>
>From the Unapproved Minutes of the Third Meeting of the IEEE Working Group
on Scheme:
5.5 Moved and accepted: Add expt to the list of procedures which
must return an exact result when given exact arguments (section 6.5.3).
Does this mean that (expt 2 50) -must- return an exact number? Suppose I
have an implementation with 32 bit FIXNUMs as my exact numbers, IEEE
FLONUMs as my inexact numbers, but no BIGNUMs. Am I forbidden from
returning a FLONUM (inexact) answer, even though my FLONUMs have the range?
Does this mean that (expt 2 50) would have to signal an error, even though
(* (expt 2 25) (expt 2 25)) would be allowed to return a FLONUM (inexact)
answer?
Whoa, calm down Alan. The list of procedures is prefixed by the
following sentence: "Finally, the procedures listed below will always
return an exact integer result provided all their arguments are exact
integers and the mathematically expected result is representable as an
exact integer within the implementation:". I don't think this should
be cause for alarm, especially since `*' is also in that list.
The editors reaffirmed their intention to substantially extend
appendix B.3, including, for instance, a discussion of the
transitivity requirements for the numeric order and equality predicates.
This should be fun. Once you start letting people take their naive notions
of how numbers should behave and turn them into -requirements-, all hell
can break lose. On what basis do you decide that the order predicates are
required to be transitive, but that + is not required to be associative?
The danger is that requirements may be adopted just in case people can
imagine a way to meet them in an implementation that uses floating point
for its inexact numbers. Unless some restraint is exercised, this can
eliminate plausible implementations of inexact numbers that aren't floating
point.
Am I missing something, or weren't you a party to the discussions at
which it was decided that transitivity was a reasonable requirement?
Looking through my archives I don't see any objections from you and
there is one particular piece of mail which shows you in favor of it.
The reason transitivity is mentioned re appendix B.3 is that we intend
to explain why it is difficult to achieve this correctly, NOT why we
decided to make it a requirement.
In any case the appendix is non-binding so that anything stated there
cannot be a requirement.
∂17-Jul-89 1603 @MC.lcs.mit.edu,@gateway.think.com:gls@think.com Numbers
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 17 Jul 89 16:03:07 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa21526;
17 Jul 89 18:58 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 17 Jul 89 18:54:27 EDT
Received: from Gateway.Think.COM by mintaka.lcs.mit.edu id aa21462;
17 Jul 89 18:50 EDT
Received: from fafnir.think.com by Think.COM; Mon, 17 Jul 89 18:50:37 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Mon, 17 Jul 89 18:48:55 EDT
Received: by verdi.think.com; Mon, 17 Jul 89 18:48:53 EDT
Date: Mon, 17 Jul 89 18:48:53 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8907172248.AA26384@verdi.think.com>
To: Alan@REAGAN.ai.mit.edu
Cc: gls@think.com, rrrs-authors@MC.lcs.mit.edu
In-Reply-To: Alan Bawden's message of Mon, 17 Jul 89 17:29 EDT <19890717212952.6.ALAN@PIGPEN.AI.MIT.EDU>
Subject: Numbers
Date: Mon, 17 Jul 89 17:29 EDT
From: Alan Bawden <Alan@reagan.ai.mit.edu>
Date: Fri, 14 Jul 89 15:51:27 EDT
From: think!gls (Guy Steele)
Subject: Confusion
I now shift my position slightly. I agree that a procedure that computes
(??? 1.4 #e1e100) ==> 9.999999999999998e99 may be useful, and that SUP is a
good name for it. I also believe that a procedure is useful that is
defined to return some one of its arguments such that the returned argument
is >= all other arguments, and that MAX is a good name for that procedure.
(One might also argue that, everything else being equal (!), MAX should
return the least-exact argument having that property, but I won't push that.)
Therefore I argue to include all of SUP, INF, MAX, and MIN.
--Guy
Except MAX and MIN have a bug with respect to the notion of exactness.
They return an exact answer when they are not entitled to. And they have
the good names, so programmers will use them and nobody will use INF and
SUP. Doing this is a subtle way of degrading the concept of an exact
number.
Of course they have the bug. That's the point. There is an inherent
conflict between the notions of "returns the biggest argument" and
"observes functional rules of exactness". So I say give the user his
choice of bugs. I am not impressed by arguments that the users will
necessarily be naive.
...
Indeed, if we do this, then MIN and MAX are unreliable in the same way that
the numeric predicates are. They will be the only numeric -functions- that
require such a warning. INF and SUP require no such warning.
So I happen to regard INF and SUP as "functions" (they really *do* something)
whereas MAX and MIN are just fancy "conditionals" (conditional selectors)
packaged up. Note that CLtL places the descriptions of the Common Lisp MAX
and MIN in the section titled "Comparisons on Numbers", along with =, <, etc.;
they are not in with +, *, etc.
--Guy
∂17-Jul-89 1757 @MC.lcs.mit.edu:Alan@REAGAN.ai.mit.edu Numbers
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 17 Jul 89 17:57:43 PDT
Received: by mintaka.lcs.mit.edu id ab22949; 17 Jul 89 20:39 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22897;
17 Jul 89 20:37 EDT
Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by MC.LCS.MIT.EDU 17 Jul 89 20:26:53 EDT
Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 237082; Mon 17-Jul-89 20:26:32 EDT
Date: Mon, 17 Jul 89 20:26 EDT
From: Alan Bawden <Alan@REAGAN.ai.mit.edu>
Subject: Numbers
To: gls@think.com
cc: rrrs-authors@MC.lcs.mit.edu
In-Reply-To: <8907172248.AA26384@verdi.think.com>
Message-ID: <19890718002629.0.ALAN@PIGPEN.AI.MIT.EDU>
Date: Mon, 17 Jul 89 18:48:53 EDT
From: gls@Think.COM (Guy Steele)
Date: Mon, 17 Jul 89 17:29 EDT
From: Alan Bawden <Alan@reagan.ai.mit.edu>
...
Except MAX and MIN have a bug with respect to the notion of exactness.
They return an exact answer when they are not entitled to. And they have
the good names, so programmers will use them and nobody will use INF and
SUP. Doing this is a subtle way of degrading the concept of an exact
number.
Of course they have the bug. That's the point. There is an inherent
conflict between the notions of "returns the biggest argument" and
"observes functional rules of exactness". So I say give the user his
choice of bugs.
Then you shouldn't mind if we make MIN and MAX behave the functional way,
and call the ones based on comparison BIGGEST and SMALLEST.
If, whenever someone doesn't like the consequences of the exactness rules,
we introduce a new procedure whose behavior he likes better, giving it the
old name and giving a new name to the old procedure, then ultimately what
good is exactness? In order to reap the benefits of exactness the user has
to write his program using a bunch of unfamiliar names (unfamiliar to
computer weenies) like INF and SUP.
The functions FLOOR, CEILING, TRUNCATE and ROUND are the next candidates
for this treatment. Shall we have two versions of each of them, one that
always returns an exact integer, even given an inexact argument, and
another that properly returns an inexact given an inexact? (Assuming an
implementation in which inexacts are floating point -- if inexacts are
intervals, then FLOOR might really be able to properly return an exact.)
There are certainly people who would prefer the former behavior, even
though the latter is the proper representation of the mathematical
functions.
I'm quite serious when I suggest that if we can't apply the notion of
exactness consistently, then we should abandon it. I would be perfectly
content if Scheme merely had some reasonable rules for floating point
numbers. But if Scheme is going to pretend to do something cleaner and
more general, based on an actual -principle-, then it shouldn't be cowardly
about applying that principle.
I am not impressed by arguments that the users will necessarily be
naive.
I am. It seems to me that the assumption that users will be naive is the
foundation of the art of programming language design. I'm certainly very
naive when I'm writing programs, and I'm grateful for a programming
language that supports me by making the naive choice also the correct
choice as often as possible.
∂17-Jul-89 1905 @mc.lcs.mit.edu:Alan@REAGAN.ai.mit.edu Numbers
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 17 Jul 89 19:05:17 PDT
Received: by mintaka.lcs.mit.edu id aa23907; 17 Jul 89 21:53 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa23823;
17 Jul 89 21:45 EDT
Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by MC.LCS.MIT.EDU 17 Jul 89 21:08:57 EDT
Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 237111; Mon 17-Jul-89 21:08:11 EDT
Date: Mon, 17 Jul 89 21:08 EDT
From: Alan Bawden <Alan@REAGAN.ai.mit.edu>
Subject: Numbers
To: cph@ZURICH.ai.mit.edu
cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: <8907172202.AA10010@zurich.ai.mit.edu>
Message-ID: <19890718010808.1.ALAN@PIGPEN.AI.MIT.EDU>
Date: Mon, 17 Jul 89 18:02:17 edt
From: cph@zurich.ai.mit.edu (Chris Hanson)
Date: Mon, 17 Jul 89 17:29 EDT
From: Alan Bawden <Alan@REAGAN.ai.mit.edu>
5.5 Moved and accepted: Add expt to the list of procedures which
must return an exact result when given exact arguments (section 6.5.3).
Does this mean that (expt 2 50) -must- return an exact number?...
Whoa, calm down Alan.
Just what did I say that made you think I had lost my calm? I was just
looking for clarification of what "-must- return an exact result" meant.
The list of procedures is prefixed by the
following sentence: "Finally, the procedures listed below will always
return an exact integer result provided all their arguments are exact
integers and the mathematically expected result is representable as an
exact integer within the implementation:". I don't think this should
be cause for alarm, especially since `*' is also in that list.
Actually, I'd be more interested to know what -isn't- on the list. I'll
bet SQRT isn't there because people think that SQRT of an exact 4 should be
allowed to return something inexact rather than an exact 2. Am I right?
I suspect that if I understood more about this "list" I would argue that
-all- numeric functions belonged on it (including SQRT).
... On what basis do you decide that the order predicates are
required to be transitive, but that + is not required to be
associative?...
Am I missing something, or weren't you a party to the discussions at
which it was decided that transitivity was a reasonable requirement?
Probably.
Looking through my archives I don't see any objections from you and
there is one particular piece of mail which shows you in favor of it.
I don't recall ever strongly advocating it, but I do recall a time when I
through it would be reasonable. I have changed my mind. After accepting
two or three of these requirements on the behavior of inexact numbers (you
will recall that we tried to add requirements so that a portable number
printer was possible), I started to worry that I couldn't see when these
requirements were going to stop accumulating.
The reason transitivity is mentioned re appendix B.3 is that we intend
to explain why it is difficult to achieve this correctly, NOT why we
decided to make it a requirement.
Well, the language that I quoted from the minutes certainly made it sound
like a requirement. (What am I -supposed- to think "transitivity
requirements" means?) I guess that's what makes those minutes unofficial.
∂17-Jul-89 2126 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #162
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 17 Jul 89 21:26:15 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa25197;
18 Jul 89 0:12 EDT
Date: 18 JUL 89 00:02:01 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #162
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID: <8907180012.aa25197@mintaka.lcs.mit.edu>
Scheme Digest #162 18 JUL 89 00:02:01 EDT
Today's Topics:
Question: "Records" in scheme?
----------------------------------------------------------------------
Date: 17 Jul 89 18:03:02 GMT
From: Brian of ASTD-CP <brian@topaz.rutgers.edu>
Subject: Question: "Records" in scheme?
Message-Id: <1455@jato.Jpl.Nasa.Gov>
Is there a way to create contiguous-memory aggregate variables in
scheme? I'd like to be able to read in some arrays of structs
created by a C program (equivalent to arrays of records in Pascal)
into scheme, parse & plot them, and translate parts of them into
scheme lists / vectors. I guess I could print the data out and
read them into scheme data structures, using ASCII as the
communication medium, but they're on the big side (several megs)
and I'd prefer to read them in "binary format" if possible.
------------------------------
End of Scheme Digest
********************
∂18-Jul-89 0833 @mc.lcs.mit.edu,@gateway.think.com:gls@think.com Numbers
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 18 Jul 89 08:33:50 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa01518;
18 Jul 89 11:28 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 18 Jul 89 11:25:02 EDT
Received: from Gateway.Think.COM by mintaka.lcs.mit.edu id aa01452;
18 Jul 89 11:23 EDT
Received: from fafnir.think.com by Think.COM; Tue, 18 Jul 89 11:23:55 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Tue, 18 Jul 89 11:22:07 EDT
Received: by verdi.think.com; Tue, 18 Jul 89 11:22:03 EDT
Date: Tue, 18 Jul 89 11:22:03 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8907181522.AA29642@verdi.think.com>
To: Alan@REAGAN.ai.mit.edu
Cc: gls@think.com, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Alan Bawden's message of Mon, 17 Jul 89 20:26 EDT <19890718002629.0.ALAN@PIGPEN.AI.MIT.EDU>
Subject: Numbers
Date: Mon, 17 Jul 89 20:26 EDT
From: Alan Bawden <Alan@reagan.ai.mit.edu>
Date: Mon, 17 Jul 89 18:48:53 EDT
From: gls@Think.COM (Guy Steele)
Date: Mon, 17 Jul 89 17:29 EDT
From: Alan Bawden <Alan@reagan.ai.mit.edu>
...
Except MAX and MIN have a bug with respect to the notion of exactness.
They return an exact answer when they are not entitled to. And they have
the good names, so programmers will use them and nobody will use INF and
SUP. Doing this is a subtle way of degrading the concept of an exact
number.
Of course they have the bug. That's the point. There is an inherent
conflict between the notions of "returns the biggest argument" and
"observes functional rules of exactness". So I say give the user his
choice of bugs.
Then you shouldn't mind if we make MIN and MAX behave the functional way,
and call the ones based on comparison BIGGEST and SMALLEST.
Despite the implied moral obligation to the contrary, in fact I do mind.
"Maximum" *means* "biggest", and "minimum" means "smallest".
However, research into the terminology leads me to another proposal.
"Supremum" and "infimum" refer to height, whereas "maximum" and "minimum"
technically (and literally) refer to *magnitude*:
Adjective superus inferus magnus parvus
Comparative superior inferior major minor
Superlative supremus infimus maximus minimus
[Yes, that really is "parvus", not something reasonable
like "minus". Don't blame me.]
From this I conclude that respect for the original meanings of the
terms would lead us to define SUP and INF to be what everyone else
calls MAX and MIN (ignoring for the moment the treatment of exactness).
We would then define (MAX A B) to be (SUP (ABS A) (ABS B)), and similarly
define MIN as INF of ABS's. But I suppose computer "science" has
already blown that one for us as well, in the same way that people
sloppily refer to a floating-point significand as a "mantissa",
or use "<>" when they mean "/=".
If, whenever someone doesn't like the consequences of the exactness rules,
we introduce a new procedure whose behavior he likes better, giving it the
old name and giving a new name to the old procedure, then ultimately what
good is exactness? In order to reap the benefits of exactness the user has
to write his program using a bunch of unfamiliar names (unfamiliar to
computer weenies) like INF and SUP.
The issue is not reaping the benefits of exactness; it is reaping the
benefits of inexactness. Let us not confuse the two.
As long as we are having fun being polemical (:-), let me also ask this
question: is it the purpose of the rrrs-authors to cater primarily to
computer weenies? (Read: to those corrupted by the accidents of prior
history?)
If the answer is "yes", then let me point out that Scheme weenies are
vastly outnumbered by C weenies, and every C weenie has the formula
#define max(x,y) ((x) > (y)) ? (x) : (y)
engraved in his little weenie brain. See? MAX really is a conditional.
The functions FLOOR, CEILING, TRUNCATE and ROUND are the next candidates
for this treatment. Shall we have two versions of each of them, one that
always returns an exact integer, even given an inexact argument, and
another that properly returns an inexact given an inexact? (Assuming an
implementation in which inexacts are floating point -- if inexacts are
intervals, then FLOOR might really be able to properly return an exact.)
There are certainly people who would prefer the former behavior, even
though the latter is the proper representation of the mathematical
functions.
There is a third possibility: if the inexactness is down at the level that
you can be sure that the integer result is exact (say you know the argument
to within .001 and it is well away from being an integer or half-integer,
as the case may be), then return an exact result; otherwise return an
inexact result (but note that the uncertainty of the result may be
relatively much, much larger than the uncertainty of the input).
I'm quite serious when I suggest that if we can't apply the notion of
exactness consistently, then we should abandon it. I would be perfectly
content if Scheme merely had some reasonable rules for floating point
numbers. But if Scheme is going to pretend to do something cleaner and
more general, based on an actual -principle-, then it shouldn't be cowardly
about applying that principle.
I agree.
I am not impressed by arguments that the users will necessarily be
naive.
I am. It seems to me that the assumption that users will be naive is the
foundation of the art of programming language design. I'm certainly very
naive when I'm writing programs, and I'm grateful for a programming
language that supports me by making the naive choice also the correct
choice as often as possible.
IBM has touted ACRITH as a system that, by using high precision and
interval arithmetic, will save you from all possible ills. See issues of
ACM SIGNUM for descriptions of why it actually loses horribly in many
cases. I suspect that inexactness as currently treated by Scheme is
no panacea.
Gee, Alan, this is fun! Best flame I've had this year.
--Guy
∂18-Jul-89 0901 @mc.lcs.mit.edu,@life.ai.mit.edu:mkatz@sesame.stanford.edu Distinct types for continuations?
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 18 Jul 89 09:01:44 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa01826;
18 Jul 89 11:53 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 18 Jul 89 11:48:53 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa01764;
18 Jul 89 11:46 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA14602; Tue, 18 Jul 89 11:45:56 EDT
Received: from sesame.Stanford.EDU (sesame.stanford.edu) by zurich.ai.mit.edu; Tue, 18 Jul 89 11:42:45 edt
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA23868; Tue, 18 Jul 89 08:44:43 PDT
Date: Tue, 18 Jul 89 08:44:43 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8907181544.AA23868@sesame.Stanford.EDU>
To: Alan@reagan.ai.mit.edu
Cc: shaff@sesame.stanford.edu, rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Alan Bawden's message of Mon, 17 Jul 89 17:46 EDT <19890717214647.7.ALAN@PIGPEN.AI.MIT.EDU>
Subject: Distinct types for continuations?
Date: Mon, 17 Jul 89 17:46 EDT
From: Alan Bawden <Alan@REAGAN.ai.mit.edu>
Date: Mon, 17 Jul 89 09:52:43 PDT
From: Mike Shaff <shaff@sesame.stanford.edu>
According to our reading of Will's denotational semantics for R3.95RS,
continuations and procedures of one argument are in different semantic domains.
Assuming that the denotational semantics hasn't changed drastically since
R3RS, this is false. The objects in the continuation domain are not handed
directly to users, and they would not function correctly if they were. If
you will look at the definition of CALL-WITH-CURRENT-CONTINUATION I think
you will find that it carefully constructs an appropriate object from the
domain of procedures.
Now, somewhat bleary eyed from staring at denotational semantics, I have come
to recognize the source of my original misinterpretation and agree with Alan
that the domains of procedures and objects returned from
call-with-current-continuation are the same. Furthermore, I am no longer as
firmly convinced that predicates which distinguish between procedures and
continuations are necessary. However, if we only have a single procedure, I
believe that PROCEDURE? is a serious misnomer. The function should really be
called APPLICABLE?.
(Perhaps the name should be changed to
"CALL-WITH-PROCEDURE-CONTAINING-CURRENT-CONTINUATION".)
Perish the thought. The name is long enough now that almost everyone uses
either CWCC or CALL/CC. I can't even imagine typing CWPCCC.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂18-Jul-89 0925 @mc.lcs.mit.edu,@life.ai.mit.edu:mkatz@sesame.stanford.edu ELSE in Scheme
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 18 Jul 89 09:25:34 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa02319;
18 Jul 89 12:20 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 18 Jul 89 12:17:54 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa02092;
18 Jul 89 12:12 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA15011; Tue, 18 Jul 89 12:12:16 EDT
Received: from sesame.Stanford.EDU (sesame.stanford.edu) by zurich.ai.mit.edu; Tue, 18 Jul 89 12:09:06 edt
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA24061; Tue, 18 Jul 89 09:11:25 PDT
Date: Tue, 18 Jul 89 09:11:25 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8907181611.AA24061@sesame.Stanford.EDU>
To: rrrs-authors@zurich.ai.mit.edu
Subject: ELSE in Scheme
The following suggestion is intended to be noncontroversial and should be
considered to be self retracting upon the first serious objection.
According to my historian, ELSE was originally introduced into Scheme because
in the old days there was no printable/typable representation for the true
object. This made it impossible to reliably specify an else clause for a COND.
The situation has changed since #t has been introduced in Scheme, and we are no
longer dependent on the tenuous binding of T to the truth object. As a result,
ELSE is no longer really needed as a syntactic keyword. I personally believe
that we should endeavor to minimize the number of keywords in Scheme. I
therefore advocate that we remove ELSE from the list of syntactic keywords and
replace ELSE by #T in the COND examples in RNRS. The dusty deck problem is
solved trivially by including (define ELSE #t) in a compatibility environment.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂18-Jul-89 1014 @mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu Numbers
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 18 Jul 89 10:13:56 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa02825;
18 Jul 89 13:01 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 18 Jul 89 12:57:24 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa02696;
18 Jul 89 12:51 EDT
Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA15541; Tue, 18 Jul 89 12:51:44 EDT
Received: from localhost by zurich.ai.mit.edu; Tue, 18 Jul 89 12:48:30 edt
Date: Tue, 18 Jul 89 12:48:30 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
Message-Id: <8907181648.AA14360@zurich.ai.mit.edu>
To: Alan@reagan.ai.mit.edu
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Alan Bawden's message of Mon, 17 Jul 89 21:08 EDT <19890718010808.1.ALAN@PIGPEN.AI.MIT.EDU>
Subject: Numbers
Date: Mon, 17 Jul 89 21:08 EDT
From: Alan Bawden <Alan@REAGAN.AI.MIT.EDU>
Date: Mon, 17 Jul 89 18:02:17 edt
From: cph@zurich.ai.mit.edu (Chris Hanson)
Whoa, calm down Alan.
Just what did I say that made you think I had lost my calm? I was just
looking for clarification of what "-must- return an exact result" meant.
My apologies -- in retrospect there was nothing to indicate this and
my flippant comment was misplaced.
Actually, I'd be more interested to know what -isn't- on the list. I'll
bet SQRT isn't there because people think that SQRT of an exact 4 should be
allowed to return something inexact rather than an exact 2. Am I right?
I suspect that if I understood more about this "list" I would argue that
-all- numeric functions belonged on it (including SQRT).
Correct. I suppose it's a matter of practicality -- nobody wanted to
commit to implement `sqrt' to handle this case specially, presumably
because such behavior isn't too interesting. To take it further, I
suppose it wouldn't hurt to add the transcendental functions to the
list, since there should be no case where exact integer arguments
produce a mathematical result which is an integer (I'm guessing on
this -- but I suspect it's true).
Here is a list of those number-valued procedures that do not appear in
the list:
/ sqrt
exp log sin cos tan asin acos atan make-polar angle
make-rectangular real-part imag-part magnitude
exact->inexact inexact->exact
The only good reason why `/' and `sqrt' should not be in the list is
efficiency and implementation complexity. Maybe that's not good
enough.
I suspect that there's no argument for keeping the transcendental
functions out of the list since my intuition tells me that there is no
case where integer arguments provide an integer result; if there is
such a case, it's probably pretty obscure, and perhaps that would be a
good reason to exclude them from the list. A similar argument holds
for `make-polar' and `angle'.
For the procedures in the third line above, I see no reason not to
include them in the list as well. Finally, `exact->inexact' clearly
cannot be in the list, while `inexact->exact' should have been
included in the first place.
Summary: the only procedures that seem to matter are `/' and `sqrt',
and the argument in favor of excluding them is pragmatic.
Am I missing something, or weren't you a party to the discussions at
which it was decided that transitivity was a reasonable requirement?
Probably.
Looking through my archives I don't see any objections from you and
there is one particular piece of mail which shows you in favor of it.
I don't recall ever strongly advocating it, but I do recall a time when I
through it would be reasonable. I have changed my mind. After accepting
two or three of these requirements on the behavior of inexact numbers (you
will recall that we tried to add requirements so that a portable number
printer was possible), I started to worry that I couldn't see when these
requirements were going to stop accumulating.
I remember those discussions. I believe that most of the requirements
were eliminated in the final draft, but the transitivity requirement
was not. I believe the reason for the transitivity requirement was to
eliminate the N-squared behavior on the number of arguments, which
seems like a pretty good reason to me.
The reason transitivity is mentioned re appendix B.3 is that we intend
to explain why it is difficult to achieve this correctly, NOT why we
decided to make it a requirement.
Well, the language that I quoted from the minutes certainly made it sound
like a requirement. (What am I -supposed- to think "transitivity
requirements" means?) I guess that's what makes those minutes unofficial.
There is an explicit transitivity requirement in the R4RS numbers
section, which was placed there after earlier discussions of which you
were a part. The IEEE Standard picked up this requirement along with
the rest of the numbers section. However, the decision reached at the
meeting was to expand the appendix to explain the consequences of this
requirement. Perhaps the minutes should be edited to make this
clearer.
∂18-Jul-89 1206 @mc.lcs.mit.edu,@gateway.think.com:gls@think.com Numbers
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 18 Jul 89 12:06:46 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa04500;
18 Jul 89 15:01 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 18 Jul 89 14:56:41 EDT
Received: from Gateway.Think.COM by mintaka.lcs.mit.edu id aa04376;
18 Jul 89 14:52 EDT
Received: from fafnir.think.com by Think.COM; Tue, 18 Jul 89 14:52:45 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Tue, 18 Jul 89 14:51:02 EDT
Received: by verdi.think.com; Tue, 18 Jul 89 14:51:00 EDT
Date: Tue, 18 Jul 89 14:51:00 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8907181851.AA02935@verdi.think.com>
To: cph@zurich.ai.mit.edu
Cc: Alan@REAGAN.ai.mit.edu, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Chris Hanson's message of Tue, 18 Jul 89 12:48:30 edt <8907181648.AA14360@zurich.ai.mit.edu>
Subject: Numbers
Date: Tue, 18 Jul 89 12:48:30 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
... I
suppose it wouldn't hurt to add the transcendental functions to the
list, since there should be no case where exact integer arguments
produce a mathematical result which is an integer (I'm guessing on
this -- but I suspect it's true).
0
e = cos 0 = 1. But you are right if you say there are *very*
few such exceptions.
∂18-Jul-89 1528 cph@zurich.ai.mit.edu test message
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 18 Jul 89 15:28:27 PDT
Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA19538; Tue, 18 Jul 89 18:01:58 EDT
Received: from localhost by zurich.ai.mit.edu; Tue, 18 Jul 89 17:58:54 edt
Date: Tue, 18 Jul 89 17:58:54 edt
From: cph@zurich.ai.mit.edu (Chris Hanson)
Message-Id: <8907182158.AA16987@zurich.ai.mit.edu>
To: rrrs-authors@ai.mit.edu
Subject: test message
This is a test, please ignore.
∂18-Jul-89 2204 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #163
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 18 Jul 89 22:04:29 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA23793; Wed, 19 Jul 89 00:20:26 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa09750;
19 Jul 89 0:05 EDT
Date: 19 JUL 89 00:01:59 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #163
To: Scheme@mc.lcs.mit.edu
Reply-To: Scheme@mc.lcs.mit.edu
Message-Id: <8907190005.aa09750@mintaka.lcs.mit.edu>
Scheme Digest #163 19 JUL 89 00:01:59 EDT
Today's Topics:
scheme for unix systems
test message
----------------------------------------------------------------------
Date: 18 Jul 89 20:06:55 GMT
From: gwusun!bleen.gwu.edu!stoler@uunet.uu.net
Subject: scheme for unix systems
Message-Id: <1418@bleen.gwusun.gwu.edu>
We are in the process of installing an HP 9000/835se and need to know of
an implementation of scheme that runs on said machine.
We also need to know of implementations that run on a SUN 3/180 and
similar machines.
Public domain implementations that can be ftp'd would be nice but commercial
products are okay too.
Thanks all.
------------------------------
Date: Tue, 18 Jul 89 18:06:27 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
Message-Id: <8907182206.AA16993@zurich.ai.mit.edu>
Subject: test message
This is a test message, please ignore.
------------------------------
End of Scheme Digest
********************
∂19-Jul-89 2155 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #164
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 19 Jul 89 21:55:37 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA12182; Thu, 20 Jul 89 00:20:05 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa24709;
20 Jul 89 0:03 EDT
Date: 20 JUL 89 00:02:08 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #164
To: Scheme@mc.lcs.mit.edu
Reply-To: Scheme@mc.lcs.mit.edu
Message-Id: <8907200003.aa24709@mintaka.lcs.mit.edu>
Scheme Digest #164 20 JUL 89 00:02:08 EDT
Today's Topics:
Scheme for unix systems
----------------------------------------------------------------------
From: Duke Briscoe <briscoe-duke@YALE.EDU>
Message-Id: <8907191538.AA13269@ELI.CS.YALE.EDU>
Date: Wed, 19 Jul 89 11:41:23 EDT
Subject: re: Scheme for unix systems
The T language has a Scheme environment which is about 99% compatible
with the Scheme standard, based on my recent experience porting
several thousand lines of Scheme code to the T system. The quality of
the T compiler is very good, producing code which is comparable in
speed to Pascal and C. It also adds some useful extensions to Scheme,
including multiple return values, a simple object system, debugger and
inspector, macros, structures, hash tables. It is available for
VAXes, Sun 3, Apollo, HPs, and both parallel and sequential versions
for Encore Multimax. According to the information I have from Lisp
Pointers Vol. 1, #6, it is available by FTP from some sites at MIT,
but I just tried there, and I couldn't find it. Maybe someone else
can give the latest info on how to get it.
-------
------------------------------
End of Scheme Digest
********************
∂20-Jul-89 1457 @mc.lcs.mit.edu,@ZERMATT.lcs.mit.edu:ziggy@hx.lcs.mit.edu BYTES (a.k.a. 1's and 0's)
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 20 Jul 89 14:57:04 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA22327; Thu, 20 Jul 89 17:38:52 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa06187;
20 Jul 89 17:33 EDT
Received: from ZERMATT.LCS.MIT.EDU (CHAOS 17316) by MC.LCS.MIT.EDU 20 Jul 89 17:33:54 EDT
Received: from HX.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via INTERNET with SMTP id 276082; 20 Jul 89 17:33:48 EDT
Received: by hx.LCS.MIT.EDU (5.51/4.7); Thu, 20 Jul 89 17:33:11 EDT
Message-Id: <2825962373-3531500@RTS-8>
Sender: ziggy@rts-8.lcs.mit.edu
Date: Thu, 20 Jul 89 17:32:53 EDT
From: "Michael R. Blair" <ziggy@hx.lcs.mit.edu>
To: rrrs-authors@zermatt.lcs.mit.edu
Subject: BYTES (a.k.a. 1's and 0's)
I am building a simulator for a computer CPU, which is much like building an
interpreter for a language. My problem is that the processor instruction set I
want to simulate includes instructions like LOGICAL-AND, SHIFT-LEFT, ROTATE,
SIGN-EXTEND and such like, for 2's complement numbers.
My problem is that I *know* that the underlying processor my Scheme is running
on has these instructions but my portable Revised↑3 implementation of Scheme
does not give me access to these underlying instructions (precisely because they
are not in the Revised↑3 manual).
It seems a *real* inconvenience to implement these (say) as procedures over
lists/vectors of booleans and I don't cherish the thought of MOD/QUOT-ing till
I'm blue in the face. And it's a shame knowing these features are just out of
reach, buried behind an abstraction barrier between my CPU and Scheme.
Has there ever been a proposal to add this stuff to the Report?
If so, what were the compelling reasons for it's rejection?
Does anyone have a Revised↑3 portable implementation of this stuff I can use
in the meantime?
Doesn't Bombin' LISP (oh, sorry... Common LISP) provide such a facility?
Should I be using a non-toy language like C instead? (;-)!!!!!!!)
Cheers,
~Ziggy
∂20-Jul-89 1631 @mc.lcs.mit.edu,@life.ai.mit.edu:jar@sid.stanford.edu Bitwise logical operations
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 20 Jul 89 16:31:18 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA23471; Thu, 20 Jul 89 19:12:36 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa07222;
20 Jul 89 19:08 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 20 Jul 89 19:08:19 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa07202;
20 Jul 89 19:04 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA23338; Thu, 20 Jul 89 19:04:18 EDT
Received: from mojave.Stanford.EDU (mojave.stanford.edu) by zurich.ai.mit.edu; Thu, 20 Jul 89 19:01:07 edt
Received: from Edusa.Stanford.EDU by mojave.Stanford.EDU (5.59/inc-1.0)
id AA23454; Thu, 20 Jul 89 16:01:31 PDT
Message-Id: <8907202301.AA23454@mojave.Stanford.EDU>
Received: by sid; Thu, 20 Jul 89 16:03:52 pdt
Date: Thu, 20 Jul 89 16:03:52 pdt
To: ziggy@hx.lcs.mit.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: "Michael R. Blair"'s message of Thu, 20 Jul 89 17:32:53 EDT <2825962373-3531500@RTS-8>
Subject: Bitwise logical operations
From: Jonathan Rees <jar%sid.stanford.edu@polya.stanford.edu>
Sender: jar@sid.stanford.edu
Come on now, you can define everything you need in Revised↑3 Scheme!
(define (lognot i)
(- -1 i))
(define (logand x y)
(cond ((= x 0) 0)
((= x -1) y)
(else
(+ (ash (logand (ash x -1) (ash y -1)) 1)
(if (and (odd? x) (odd? y)) 1 0)))))
(define (logior x y)
(lognot (logand (lognot x) (lognot y))))
(define (logxor x y)
(logand (lognot (logand x y)) (logior x y)))
(define (ash n m)
(define (ash-nonnegative n m)
(if (> m 0)
(* n (expt 2 m))
(quotient n (expt 2 (- m)))))
(cond ((or (= m 0) (= n 0)) n)
((> n 0) (ash-nonnegative n m))
((> m 0)
(- (ash-nonnegative (- n) m)))
(else
(lognot (ash-nonnegative (lognot n) m)))))
Seriously, however, I agree with you. I think Scheme should include
two's-complement bitwise logical operations that work on integers.
I'd suggest adding to the report something similar to a subset of what
Common Lisp provides. How about:
(logand i1 ...)
(logior i1 ...)
(logxor i1 ...)
(lognot i)
(ash i1 i2)
(integer-length i)
with the same meanings as in Common Lisp (assuming I remember the
Common Lisp names properly). Of course they have to be insensitive to
word length.
Load bit field and deposit bit field are also pretty useful, but I
wouldn't advocate inventing a byte specifier pseudo-type like CL does.
Nor would I approve of CL's argument order, which I find impossible to
remember.
Logical shift and rotate don't make sense unless a word size is
supplied. They can be synthesized pretty easily given the other
operations, so I'd say don't include them.
∂21-Jul-89 0124 @mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com Re: last call: changes for R4RS
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Jul 89 01:23:54 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA28369; Fri, 21 Jul 89 04:11:21 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa12217;
21 Jul 89 2:42 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Jul 89 02:42:32 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa12174;
21 Jul 89 2:38 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA27578; Fri, 21 Jul 89 02:38:11 EDT
Received: from Xerox.COM (xerox.com) by zurich.ai.mit.edu; Fri, 21 Jul 89 02:35:07 edt
Received: from Semillon.ms by ArpaGateway.ms ; 20 JUL 89 10:33:29 PDT
Date: Thu, 20 Jul 89 10:34:19 PDT
From: Pavel.pa@xerox.com
Subject: Re: last call: changes for R4RS
In-Reply-To: <8907130003.AA17137@spencer.cs.uoregon.edu>
To: rrrs-authors@zurich.ai.mit.edu
Message-Id: <890720-103329-118@Xerox>
I'd rather that we did not cut off debate on R4RS at the end of this month.
It seems to me that there are several reasonably important issues currently
on the table that could make it into R4RS in the very near future (e.g.,
uniform definition semantics, fluid binding, and regularization of
procedures). I would hate to see R4RS come out so little changed from the
previous report; in a sense, what's the point?
I do, however, understand the desire of the IEEE group to have a solid
commitment from the authors very soon. They might be satisfied, though,
with a promise that the set of valid R4RS programs will be a superset of
the valid R3.99RS programs. None of the proposals I mentioned above
violate this promise (the only non-trivial case is uniform definition
semantics; the liberalized semantics supported by John Ramsdell and me does
not change the meaning of any valid R3.95RS program). In this way, the
IEEE group can proceed with the assurance that they will publish a
conservative subset of R4RS without requiring that report to be finalized
immediately.
Pavel
∂21-Jul-89 0125 @mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com Re: last call: changes for R4RS
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Jul 89 01:24:59 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA28375; Fri, 21 Jul 89 04:14:15 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa12219;
21 Jul 89 2:42 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Jul 89 02:42:41 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa12176;
21 Jul 89 2:38 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA27581; Fri, 21 Jul 89 02:38:25 EDT
Received: from Xerox.COM (xerox.com) by zurich.ai.mit.edu; Fri, 21 Jul 89 02:35:16 edt
Received: from Semillon.ms by ArpaGateway.ms ; 20 JUL 89 10:58:57 PDT
Date: Thu, 20 Jul 89 10:59:23 PDT
From: Pavel.pa@xerox.com
Subject: Re: last call: changes for R4RS
In-Reply-To: <8907130003.AA17137@spencer.cs.uoregon.edu>
To: rrrs-authors@zurich.ai.mit.edu
Message-Id: <890720-105857-125@Xerox>
Controversial changes requiring positive action by the authors if they
are
to be adopted in the R4RS:
Section 6.3.
P1178 has requested again that LIST-REF be made essential, for
parallelism
with VECTOR-REF and STRING-REF. Their previous request that LIST-TAIL
be
made essential has been dropped.
I support this, strongly if the other non-controversial regularization
proposals are also accepted, and more weakly otherwise.
Section 6.5.5.
P1178 has requested that MIN and MAX be renamed INF and SUP. The
rationale
is that the somewhat surprising behavior of MIN and MAX when given
mixed
exact and inexact arguments would be more acceptable if their names
were
less familiar. A second rationale is that the fact that the
mathematical
infimum and supremum operations, when given an infinite set of
"arguments",
may return a result that is not in the argument set; this is the
surprising
thing about MIN and MAX, e.g. (MAX 1.4 #e1e100) ==>
9.999999999999998e99.
Background: In any case, a note will be added to point out and explain
this
behavior, which is required in order for exact results to be trusted.
It
happens that MIN and MAX behave this way in Common Lisp as well,
although
the motivation was rather different.
I believe that I agree with GLS on this one. I do not see MAX as an
operation that computes a result in the same sense as addition. Rather, it
is a convenient packaging of a common use of the <= function. It seems to
me inconsistent that MAX should behave differently than the obvious
rewriting in terms of <=. Once <= establishes a total order on the numbers
in any given implementation, MAX should perform the simple operation
implied by its name; that is, it should return the largest element in the
set of its arguments. Just as <= does not return an ``inexact'' boolean,
MAX should not be affected by the exactness of its arguments.
I would have no problem with a repetition under MAX of the warning under <=
about comparing inexact numbers, so long as MAX is defined to return one of
its arguments. If others have a great use for INF and SUP (by which I mean
what some are describing as the current semantics for MIN and MAX) then I
suppose I won't stand in the way; however, I feel strongly about the proper
meaning of MIN and MAX.
Noncontroversial changes that will be adopted in the R4RS unless the
authors
object:
...
Section 6.2.
EQV?-ness is preserved when storing into and fetching from the standard
data structures (pairs, vectors, strings). [Note: EQ?-ness isn't
necessarily preserved. Preservation of EQV?-ness implies preservation
of exactness, which is the context in which P1178 requested this
change.]
I would be unhappy with any statement that distinguished between the
behavior of, for example, the car cell of a pair and the contents of a
lexical variable; EQ?-ness should not be guaranteed for one but not the
other. Thus, I support this change only if it is extended to include
variables. Pragmatically, the storage for a variable is just as likely to
be type-specialized as that for a pair or vector.
Pavel
∂21-Jul-89 0342 @mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com Re: legion
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Jul 89 03:42:19 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA29094; Fri, 21 Jul 89 06:30:36 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa12221;
21 Jul 89 2:43 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Jul 89 02:42:50 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa12178;
21 Jul 89 2:38 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA27582; Fri, 21 Jul 89 02:38:26 EDT
Received: from Xerox.COM (xerox.com) by zurich.ai.mit.edu; Fri, 21 Jul 89 02:35:22 edt
Received: from Semillon.ms by ArpaGateway.ms ; 20 JUL 89 11:10:44 PDT
Date: Thu, 20 Jul 89 11:11:17 PDT
From: Pavel.pa@xerox.com
Subject: Re: legion
In-Reply-To: <8907130005.AA17154@spencer.cs.uoregon.edu>
To: rrrs-authors@zurich.ai.mit.edu
Message-Id: <890720-111044-128@Xerox>
Date: Wed, 12 Jul 89 17:05:39 PDT
From: will@cs.uoregon.edu
If indeed we must add fluid variables to the language, then I think that
we should do something very like Pavel's proposal. I'm not keen on
adding fluid variables, however. If we are to add any dynamic features
I'd rather add DYNAMIC-WIND, which seems simpler and more useful. If
we had DYNAMIC-WIND and a macro package, then people could pull their
favorite semantics for fluid variables out of the yellow pages.
Unfortunately, DYNAMIC-WIND is not enough. There appears to be a great
deal of confusion between the capabilities offered by DYNAMIC-WIND and
fluid binding; the two are completely orthogonal in general. In
particular, on a shared-memory multiprocessor (I feel like a broken
record...), DYNAMIC-WIND cannot be used to implement fluid binding. It can
only be used for shallow-binding implementations and, as I've described
twice already, shallow-binding cannot work correctly on a shared-memory
multiprocessor.
I would support an additional proposal to add DYNAMIC-WIND to the language,
but cannot support it to the exclusion of fluid binding. If we are to
avoid discrimination against multiprocessor implementations like Scheme
Xerox, fluid binding must be a part of the language, not a yellow pages
package.
Will:
2. (This reason is pretty weak.) For the compiler writer, I
think the freedom to rearrange definitions makes closure
analysis a little simpler when procedure definitions are
mixed with definitions of variables containing non-procedure
values.
This is incorrect. The compiler would still have the freedom to move
procedure definitions in front of other definitions, since it could
make a difference only if the program is in error. Once the procedure
definitions have been grouped together, their order makes no difference
under either semantics.
Given your retraction of this objection and John's and my unanswered
refutations of your first one, may we assume that you now support the
proposal to unify definition semantics? If not, could you say more?
Pavel
∂21-Jul-89 0346 @mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com Re: Regularization of list, vector, and string procedures
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Jul 89 03:46:16 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA29100; Fri, 21 Jul 89 06:32:22 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa12223;
21 Jul 89 2:43 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Jul 89 02:42:58 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa12180;
21 Jul 89 2:38 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA27587; Fri, 21 Jul 89 02:38:31 EDT
Received: from Xerox.COM (xerox.com) by zurich.ai.mit.edu; Fri, 21 Jul 89 02:35:26 edt
Received: from Semillon.ms by ArpaGateway.ms ; 20 JUL 89 11:40:06 PDT
Date: Thu, 20 Jul 89 11:32:07 PDT
From: Pavel.pa@xerox.com
Subject: Re: Regularization of list, vector, and string procedures
In-Reply-To: <8907130007.AA17164@spencer.cs.uoregon.edu>
To: rrrs-authors@zurich.ai.mit.edu
Message-Id: <890720-114006-139@Xerox>
Morry suggested adding a procedure named ``list?'' to test for a
null-terminated list. Will approved, but preferred the name
``proper-list?''.
I thought this as well (the function is called ``proper-list?'' in Cedar
Scheme) and almost said so in my response to Morry. First, however, I
looked up the definition of lists in R3RS. In contrast to CLtL, which
explicitly allows ``list'' to refer both to ``true lists''
(null-terminated) and ``dotted lists'', R3RS is fairly strict on the point.
It says,
``A chain of pairs not ending in the empty list is called
an IMPROPER LIST. Note that an improper list is not a list.''
I thus concluded that ``proper-list?'' was a redundant name and that
``list?'' was more appropriate. I don't feel very strongly about this,
though.
Will also says:
I'd prefer to avoid generic procedures at the lowest levels of Scheme.
Why not have LIST-APPLY, VECTOR-APPLY, and STRING-APPLY, by analogy with
LIST-LENGTH, VECTOR-LENGTH, and STRING-LENGTH etc?
Assuming that ``apply'' is initially bound to the same value as
``list-apply'', I don't object to this proposal. It will be amusing to see
if I ever find a use for either of ``vector-apply'' or ``string-apply''.
Finally, Will made a proposal for higher-order functions ``make-map'' and
``make-for-each'' to provide for generalized mapping functionality. I have
two objections to the proposal:
-- Since ``make-map'' takes a ``ref'' procedure for each aggregate
argument, it takes quadratic time to map down lists and other linked
structures. While it might be the case, as Will states, that make-map
``could be made equally efficient for the cases that could be handled by
generic MAP'' (though I don't see how, in general), this inefficiency could
not be overcome for other, user-defined linked structures. Thus, the
proposal is not as generally applicable as it might initially seem.
-- Such a facility crosses my threshold for the amount of experimentation
appropriate in the report. To my knowledge, no implementation has any
experience with such a facility. Thus, I would rather leave ``map'' and
``for-each'' as unsolved problems in R4RS and have Will or someone else
contribute an implementation of ``make-map'' and ``make-for-each'' to the
library. Then we could all play around with them for a while before
committing them to the report.
Pavel
∂21-Jul-89 0453 ramsdell@linus.mitre.org Priorities
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Jul 89 04:52:59 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA29624; Fri, 21 Jul 89 07:33:00 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA28604; Fri, 21 Jul 89 07:29:25 EDT
Posted-Date: Fri, 21 Jul 89 07:29:03 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA06493; Fri, 21 Jul 89 07:29:04 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8907211129.AA06493@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Cc: ramsdell@linus.mitre.org
Subject: Priorities
Date: Fri, 21 Jul 89 07:29:03 EDT
I am worried that the important issues are being lost in this debate.
Let me give you my ranking of the issues.
(1) Issues from Snowbird.
[A] Macros: I had hoped to see some form of syntactic closures in
R4RS. I have heard there is no acceptable implementation
of extend-syntax using syntactic closures yet. It appears we
must find an alternative to the Snowbird macro compromise.
[B] Regularization of Procedure Names: This is being discussed as
it should be.
(2) Post Snowbird issues.
[A] Uniform Definition Semantics: Adding macros to Scheme may
affect this proposal.
[B] Fluid Binding: Didn't Pavel say something about how this issue
should be easy?
(3) Post R4RS issues.
[A] Multiple Value Return: We nearly had agreement, I suspect we
could reach agreement in time for R5RS.
[B] Modules: There are no proposals on the table, but keep thinking!
I do not want to imply that the other issues being debated are not
worth discussing. For example, I support the addition of bitwise
logical operators. I just hope the above list of issues does not get
lost.
John
∂21-Jul-89 0553 @mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com Re: ELSE in Scheme
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Jul 89 05:53:50 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA00377; Fri, 21 Jul 89 08:39:42 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa12227;
21 Jul 89 2:43 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Jul 89 02:43:13 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa12184;
21 Jul 89 2:38 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA27591; Fri, 21 Jul 89 02:38:39 EDT
Received: from Xerox.COM (xerox.com) by zurich.ai.mit.edu; Fri, 21 Jul 89 02:35:35 edt
Received: from Semillon.ms by ArpaGateway.ms ; 20 JUL 89 20:07:57 PDT
Date: Thu, 20 Jul 89 12:05:04 PDT
From: Pavel.pa@xerox.com
Subject: Re: ELSE in Scheme
In-Reply-To: <8907181611.AA24061@sesame.Stanford.EDU>
To: rrrs-authors@zurich.ai.mit.edu
Message-Id: <890720-200757-1264@Xerox>
I would rather see ELSE remain in the language. The old LISP idiom of
using T as the predicate in the final COND-clause always struck me as a
hack that sort of ``happens'' to work. In my mind ELSE is more abstract
and thus easier to read. I remember, as a Common Lisp programmer, first
reading about Scheme and being pleased with ELSE's presence. I always used
OTHERWISE at the end of my Common Lisp CASE expressions, too.
Pavel
∂21-Jul-89 0807 @mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com Re: Fluid binding
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Jul 89 08:07:22 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA01820; Fri, 21 Jul 89 10:45:47 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa12225;
21 Jul 89 2:43 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Jul 89 02:43:07 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa12182;
21 Jul 89 2:38 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA27590; Fri, 21 Jul 89 02:38:36 EDT
Received: from Xerox.COM (xerox.com) by zurich.ai.mit.edu; Fri, 21 Jul 89 02:35:30 edt
Received: from Semillon.ms by ArpaGateway.ms ; 20 JUL 89 20:07:15 PDT
Date: Thu, 20 Jul 89 12:01:25 PDT
From: Pavel.pa@xerox.com
Subject: Re: Fluid binding
In-Reply-To: <8907130921.AA28558@hpda.HP.COM>
To: rrrs-authors@zurich.ai.mit.edu
Message-Id: <890720-200715-1255@Xerox>
Date: Thu, 13 Jul 89 02:20:39 pdt
From: Guillermo J. Rozas <jinx@hpesogg.hp.com>
I think calling these objects fluid "variables" in the context of
other Scheme variables is very misleading. Lexical (ordinary) Scheme
variables can't be aliased, since their addresses cannot be passed
around. These can. Lexical variables can only be affected by special
forms, these can be affected (and usually are) by procedures. Lexical
variables are not first class, they are not even objects since they
are not expressible values. Yours are first class objects. It seems
to me that these fluid variables are much more similar to pairs than
to anything else in the language.
Let's put it another way. In the absence of FLUID-LET, what is the
difference between your fluids and 1-slot records? Your
interpretation is that there is a lot of hair in fluid environments,
etc. Mine is simpler: there are cells, and there is a special form
which establishes a temporary/isolated contents for them. Except for
efficiency, there is no reason why that could not be generalized to
pairs, vectors, etc.
Fascinating; your perspective is completely opposite to mine. You ask,
``In the absence of FLUID-LET, what is the difference between your fluids
and 1-slot records?'' The answer, clearly, is ``nothing''. But FLUID-LET
is the whole issue, isn't it? You perceive my interpretation in terms of a
fluid environment as ``a lot of hair'', but it seems to me this idea os
``temporary/isolated contents'' is considerably hairier. In particular,
FLUID-LET in your interpretation is a side-effect that must carefully be
un-done or re-done whenever control leaves or re-enters the body of the
form. This seems very messy to me, conceptually; I shudder to think how it
would look when added to the formal semantics. A fluid environment, on the
other hand, is another instance of a well-understood concept. It is
essentially trivial to add it to the formal semantics, and under that
conception, FLUID-LET is no more a side-effect than LET.
Perhaps we can avoid having to convince one another on this issue, however.
If you could agree to leave the names MAKE-FLUID, FLUID-REF, FLUID-SET!,
FLUID-LET, and WITH-FLUID-BINDING, I would certainly have no problem with
describing both conceptions in the informal definition in the report.
This brings up the issue of using the name FLUID-LET even though it
currently has different meanings in certain implementations. I suggested
renaming the current forms to make way for the new meaning. Jinx replied:
Your solution assumes that you can reach all code that used FLUID-LET.
That is unlikely in a wide-spread implementation.
But surely a wide-spread implementation has some social mechanism by which
the changes in the supported language are communicated to the users. Let
your release notes mention prominently that the name of the form has
changed. The fix to user code is easy for each user to apply.
A second objection is purely based on the name. I don't think that
FLUID-LET is a very appropriate name for your form, since it is (in my
mind, where all you are doing is data structure manipulation)
unrelated to LET. I'd much rather have your form be called ISOLATE,
TEMPORARILY, or something like that.
As noted above, I disagree strongly with this conception of what's going on
in these forms. Can we find some middle ground that lets both of us retain
our models?
Hopefully,
Pavel
∂21-Jul-89 0812 @mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com last call: changes for R4RS
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Jul 89 08:11:28 PDT
Received: from Score.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AB01839; Fri, 21 Jul 89 10:48:18 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa14471;
21 Jul 89 6:08 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Jul 89 06:07:53 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa14438;
21 Jul 89 6:00 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA28950; Fri, 21 Jul 89 06:00:10 EDT
Received: from sde.hp.com (sde.hp.com) by zurich.ai.mit.edu; Fri, 21 Jul 89 05:57:06 edt
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.6b/SES42.42) id AA09171; Fri, 21 Jul 89 02:59:50 pdt
Message-Id: <8907210959.AA09171@sde.hp.com>
Received: by hpesogg; Fri, 21 Jul 89 02:58:57 pdt
Date: Fri, 21 Jul 89 02:58:57 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Pavel.pa@xerox.com's message of Thu, 20 Jul 89 10:59:23 PDT <890720-105857-125@Xerox>
Subject: last call: changes for R4RS
Reply-To: jinx%hpesogg@sde.hp.com
I believe that I agree with GLS on this one. I do not see MAX as an
operation that computes a result in the same sense as addition. Rather, it
is a convenient packaging of a common use of the <= function. It seems to
me inconsistent that MAX should behave differently than the obvious
rewriting in terms of <=. Once <= establishes a total order on the numbers
in any given implementation, MAX should perform the simple operation
implied by its name; that is, it should return the largest element in the
set of its arguments. Just as <= does not return an ``inexact'' boolean,
MAX should not be affected by the exactness of its arguments.
I don't understand people's desire for MAX/SUP and MIN/INF to return a
result EQV? to one of the inputs.
Perhaps there is still confusion about the issues, so let's consider
the consequences in a typical implementation (all inexact reals are
represented as floating point, exact integers have unlimited range):
- max/sup is given a set of exact reals. The result will be an exact
real both = and eqv? to one of the inputs. No surprises here.
- max/sup is given a set of inexact numbers. The result will be an
inexact number both = and eqv? to one of the inputs. No surprises here.
- max/sup is given a mixture of exact numbers and inexact numbers:
The first observation is that the fact that the result is inexact
should cause no problems in code, since after all, the inputs were of
mixed exactness and thus the "largest input" might easily have been
inexact. In particular doing (vector-ref v (max ...)) where the
arguments to max are of mixed exactness is clearly foolish. Thus the
only problem is the fact that the result may not be eqv? or even = to
one of the inputs.
The possibilities are as follows:
1) The "largest" input happens to be inexact. No surprises here.
2) The "largest" input is exact, and its value can be represented as
an inexact number without any loss of precision. The result will be =
to one of the inputs, although not eqv?
3) The "largest" input is exact, but its value is too large be
represented as an inexact number. It seems to me that under these
circumstances a good implementation should signal an implementation
error because of an out of range coercion.
4) The "largest" input is exact, but its value cannot be represented
as an inexact number without loss of precision (the bignum has more
significant bits than the length of the mantissa in the floating point
representation). A good implementation would coerce to floating point
rounding towards infinity (ie. add 1 at the least significant mantissa
bit after truncating the bits) in order to return a value >= than all
the inputs.
Thus the "surprises" arise from cases 2, 3, and 4 above.
I think that cases 3 and 4 are rare, since mixed bignum/inexact
computation is not common (in my experience). The level of surprise
here is pretty low. Case 3 in particular would probably be less
surprising, although more annoying. Note also that cases 3 and 4 can
be "fixed" if the implementation includes an exactness bit for
bignums, since the result would then be = to one of the inputs.
Case 2 is the only really surprising case. This arises from max/sup'ing
2 and 1.5, for example. How surprising is it really? The result is =
to the largest input, and depending on eqv? of the result is at best
obscure, so the only surprise would come in output, where the inexact
value would have a decimal digit and the exact would not.
Is this really so worrisome to everyone? It seems to me that the
people worried about the surprise factor are worrying too much about
exactly one case, namely what their interactive system will print when
they call max/sup or min/inf from top level, but that is not very
interesting, or worth worrying much about.
PS:
(define (max/sup a b)
(/ (+ (+ a b) (abs (- a b)))
2))
[Modulo overflow or roundoff]
Inexact contagion implies that the result should be inexact if either
input is inexact.
∂21-Jul-89 1019 @mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com legion
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Jul 89 10:19:25 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA03373; Fri, 21 Jul 89 12:54:40 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa15136;
21 Jul 89 7:44 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Jul 89 07:44:31 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa15117;
21 Jul 89 7:40 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA29723; Fri, 21 Jul 89 07:40:12 EDT
Received: from sde.hp.com (sde.hp.com) by zurich.ai.mit.edu; Fri, 21 Jul 89 07:37:08 edt
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.6b/SES42.42) id AA10355; Fri, 21 Jul 89 04:39:56 pdt
Message-Id: <8907211139.AA10355@sde.hp.com>
Received: by hpesogg; Fri, 21 Jul 89 04:39:05 pdt
Date: Fri, 21 Jul 89 04:39:05 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Pavel.pa@xerox.com's message of Thu, 20 Jul 89 11:11:17 PDT <890720-111044-128@Xerox>
Subject: legion
Reply-To: jinx%hpesogg@sde.hp.com
Unfortunately, DYNAMIC-WIND is not enough. There appears to be a great
deal of confusion between the capabilities offered by DYNAMIC-WIND and
fluid binding; the two are completely orthogonal in general. In
particular, on a shared-memory multiprocessor (I feel like a broken
record...), DYNAMIC-WIND cannot be used to implement fluid binding. It can
only be used for shallow-binding implementations and, as I've described
twice already, shallow-binding cannot work correctly on a shared-memory
multiprocessor.
I agree that dynamic-wind is not enough, but it is not independent of
fluid-binding. The multiprocessor implementation of fluid binding can
still be based on dynamic-wind:
(fluid-let ((<cell> <value>))
<code>)
expands into
(with-new-fluid-value <cell> <value> (lambda () <code>))
with
(define (with-new-fluid-value fluid-cell new-value thunk)
(with-fluid-bindings-list
(cons (cons fluid-cell new-value)
(get-fluid-bindings-list))
thunk))
(define (with-fluid-bindings-list inside)
(let ((outside (get-fluid-bindings-list)))
(dynamic-wind
(lambda ()
(set-fluid-bindings-list! inside))
thunk
(lambda ()
(set-fluid-bindings-list! outside)))))
(define (user-cwcc receiver)
(with-fluid-bindings-list
(get-fluid-bindings-list)
(lambda ()
(primitive-cwcc-that-knows-about-dynamic-wind
receiver))))
Where set/get-fluids-bindings-list operate on the process/processor state.
Dynamic-wind still offers the correct isolation between the region
with the new binding and the region with the original binding. The
difference is how the entry and exit thunks swap bindings.
∂21-Jul-89 1220 cph@zurich.ai.mit.edu test
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Jul 89 12:20:36 PDT
Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA04573; Fri, 21 Jul 89 14:29:07 EDT
Received: from localhost by zurich.ai.mit.edu; Fri, 21 Jul 89 14:26:04 edt
Date: Fri, 21 Jul 89 14:26:04 edt
From: cph@zurich.ai.mit.edu (Chris Hanson)
Message-Id: <8907211826.AA04776@zurich.ai.mit.edu>
To: scheme-inbox@ai.mit.edu
Subject: test
Another test message, please ignore.
∂21-Jul-89 1449 @mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com Regularization of list, vector, and string procedures
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Jul 89 14:49:11 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA06938; Fri, 21 Jul 89 17:27:35 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa15291;
21 Jul 89 8:04 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Jul 89 08:04:41 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa15232;
21 Jul 89 7:57 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA29809; Fri, 21 Jul 89 07:56:58 EDT
Received: from sde.hp.com (sde.hp.com) by zurich.ai.mit.edu; Fri, 21 Jul 89 07:53:42 edt
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.6b/SES42.42) id AA10576; Fri, 21 Jul 89 04:56:29 pdt
Message-Id: <8907211156.AA10576@sde.hp.com>
Received: by hpesogg; Fri, 21 Jul 89 04:55:30 pdt
Date: Fri, 21 Jul 89 04:55:30 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Pavel.pa@xerox.com's message of Thu, 20 Jul 89 11:32:07 PDT <890720-114006-139@Xerox>
Subject: Regularization of list, vector, and string procedures
Reply-To: jinx%hpesogg@sde.hp.com
I thought this as well (the function is called ``proper-list?'' in Cedar
Scheme) and almost said so in my response to Morry. First, however, I
looked up the definition of lists in R3RS. In contrast to CLtL, which
explicitly allows ``list'' to refer both to ``true lists''
(null-terminated) and ``dotted lists'', R3RS is fairly strict on the point.
It says,
``A chain of pairs not ending in the empty list is called
an IMPROPER LIST. Note that an improper list is not a list.''
I thus concluded that ``proper-list?'' was a redundant name and that
``list?'' was more appropriate. I don't feel very strongly about this,
though.
I feel relatively strongly about it. At the original r2rs meeting I
suggested calling it list? since I had always felt that the concept of
a "proper list" was funny. I don't remember whether it made it into
r2rs and was then flushed, or what happened, but I would not like it
to be called proper-list?.
I'd prefer to avoid generic procedures at the lowest levels of Scheme.
Why not have LIST-APPLY, VECTOR-APPLY, and STRING-APPLY, by analogy with
LIST-LENGTH, VECTOR-LENGTH, and STRING-LENGTH etc?
Assuming that ``apply'' is initially bound to the same value as
``list-apply'', I don't object to this proposal. It will be amusing to see
if I ever find a use for either of ``vector-apply'' or ``string-apply''.
I don't see a point to STRING-APPLY or VECTOR-APPLY (except to be used
with STRING or VECTOR to copy a string or vector). I think we should
leave APPLY alone for the following reasons:
- Apply is not really an operation on lists. It is a hook into the
procedure calling mechanism of the language so that procedures with
arbitrary arity can be called with arbitrary numbers of arguments.
Applying to lists is traditional, although funny in the same way that
arbitrary arity procedures (procedures with dotted lambda lists) build
lists.
The right way to fix APPLY is not to generalize it along its spurious
direction, but to devise some way by which we can drop user data
structures altogether from this hook into the system, for example, by
designing an alternative based on procedures.
- The kind of manipulation where apply is used is more conveniently
done on lists than on any other data structures. It is also natural
to think of argument lists as lists, rather than vectors or strings.
I agree that MAP and FOR-EACH should be left alone for the time
being.
∂21-Jul-89 1642 @mc.lcs.mit.edu,@life.ai.mit.edu:gls@think.com last call: changes for R4RS
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Jul 89 16:41:48 PDT
Received: from MINTAKA.LCS.MIT.EDU by life.ai.mit.edu (4.1/AI-4.10) id AB08183; Fri, 21 Jul 89 19:28:15 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa17889;
21 Jul 89 12:25 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Jul 89 12:24:51 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa17868;
21 Jul 89 12:22 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02981; Fri, 21 Jul 89 12:22:33 EDT
Received: from Think.COM ([131.239.2.1]) by zurich.ai.mit.edu; Fri, 21 Jul 89 12:19:18 edt
Received: from fafnir.think.com by Think.COM; Fri, 21 Jul 89 12:20:52 EDT
Received: from verdi.think.com by fafnir.think.com; Fri, 21 Jul 89 12:18:59 EDT
Received: by verdi.think.com; Fri, 21 Jul 89 12:18:56 EDT
Date: Fri, 21 Jul 89 12:18:56 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8907211618.AA19787@verdi.think.com>
To: jinx%hpesogg@sde.hp.com
Cc: Pavel.pa@xerox.com, rrrs-authors@zurich.ai.mit.edu
In-Reply-To: "Guillermo J. Rozas"'s message of Fri, 21 Jul 89 02:58:57 pdt <8907210959.AA09171@sde.hp.com>
Subject: last call: changes for R4RS
Date: Fri, 21 Jul 89 02:58:57 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
...
Case 2 is the only really surprising case. This arises from max/sup'ing
2 and 1.5, for example. How surprising is it really? The result is =
to the largest input, and depending on eqv? of the result is at best
obscure, so the only surprise would come in output, where the inexact
value would have a decimal digit and the exact would not.
Is this really so worrisome to everyone? It seems to me that the
people worried about the surprise factor are worrying too much about
exactly one case, namely what their interactive system will print when
they call max/sup or min/inf from top level, but that is not very
interesting, or worth worrying much about.
Well, I think it is worth worrying about.
PS:
(define (max/sup a b)
(/ (+ (+ a b) (abs (- a b)))
2))
[Modulo overflow or roundoff]
Actually, I had considered including this very definition in my initial
message as a joke. But it muddies the issue. Completely aside from
questions of overflow, I think this is not the model of MAX that most
programmers carry around in their heads.
Inexact contagion implies that the result should be inexact if either
input is inexact.
(1) I see no reason why the rules of inexact contagion should
apply to MAX. As Pavel has observed, >= does not return an
inexact boolean. (If >= were to be three-valued (yes/no/maybe)
then it would be more consistent.)
(2) The requirement of contagion is particularly onerous in the
case where it results in an implementation producing a range error
when simply returning the exact argument would have been fine.
(N.B. With IEEE 754 floating-point arithmetic there is at least
an explicit representation of infinity. Maybe non-754 floating-point
should be declared broken and therefore forbidden by the Scheme standard.)
--Guy
∂21-Jul-89 1649 @mc.lcs.mit.edu,@life.ai.mit.edu:mkatz@sesame.stanford.edu ELSE in Scheme
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Jul 89 16:49:01 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA08328; Fri, 21 Jul 89 19:35:44 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa17991;
21 Jul 89 12:37 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Jul 89 12:37:09 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa17966;
21 Jul 89 12:34 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02730; Fri, 21 Jul 89 12:05:01 EDT
Received: from sesame.Stanford.EDU (sesame.stanford.edu) by zurich.ai.mit.edu; Fri, 21 Jul 89 12:01:51 edt
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA09018; Fri, 21 Jul 89 09:03:59 PDT
Date: Fri, 21 Jul 89 09:03:59 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8907211603.AA09018@sesame.Stanford.EDU>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Pavel.pa@xerox.com's message of Thu, 20 Jul 89 12:05:04 PDT <890720-200757-1264@Xerox>
Subject: ELSE in Scheme
Date: Thu, 20 Jul 89 12:05:04 PDT
From: Pavel.pa@xerox.com
I would rather see ELSE remain in the language. The old LISP idiom of
using T as the predicate in the final COND-clause always struck me as a
hack that sort of ``happens'' to work. In my mind ELSE is more abstract
and thus easier to read. I remember, as a Common Lisp programmer, first
reading about Scheme and being pleased with ELSE's presence. I always used
OTHERWISE at the end of my Common Lisp CASE expressions, too.
Pavel
My proposal does not prevent you from using else within CONDs in your programs.
As stated in my original message, all you have to do is put the definition
(define else #t) in your program. Furthermore, if you prefer the term
OTHERWISE you could use this instead and include the definition
(define otherwise #t) in your programs. All I wanted was to remove ELSE from
the list of syntactic keywords so that other people, myself included, can use
the identifier ELSE for other purposes if we so choose.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂21-Jul-89 1854 @mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu last call: changes for R4RS
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Jul 89 18:53:57 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA09344; Fri, 21 Jul 89 21:39:56 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa19581;
21 Jul 89 14:45 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Jul 89 14:45:19 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa19451;
21 Jul 89 14:41 EDT
Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA04753; Fri, 21 Jul 89 14:41:08 EDT
Received: from localhost by zurich.ai.mit.edu; Fri, 21 Jul 89 14:38:05 edt
Date: Fri, 21 Jul 89 14:38:05 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
Message-Id: <8907211838.AA04787@zurich.ai.mit.edu>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Pavel.pa@xerox.com's message of Thu, 20 Jul 89 10:59:23 PDT <890720-105857-125@Xerox>
Subject: last call: changes for R4RS
Date: Thu, 20 Jul 89 10:59:23 PDT
From: Pavel.pa@xerox.com
Noncontroversial changes that will be adopted in the R4RS unless the
authors object:
...
Section 6.2.
EQV?-ness is preserved when storing into and fetching from the standard
data structures (pairs, vectors, strings). [Note: EQ?-ness isn't
necessarily preserved. Preservation of EQV?-ness implies preservation
of exactness, which is the context in which P1178 requested this
change.]
I would be unhappy with any statement that distinguished between the
behavior of, for example, the car cell of a pair and the contents of a
lexical variable; EQ?-ness should not be guaranteed for one but not the
other. Thus, I support this change only if it is extended to include
variables. Pragmatically, the storage for a variable is just as likely to
be type-specialized as that for a pair or vector.
I agree, though I would go slightly further, if the wording can be
worked out: since we have a definition of the "store" in the report,
can we say that EQV?-ness is preserved when storing and fetching from
these locations? If worded correctly I think that can capture the
essence of what we need to say here.
∂21-Jul-89 1856 @mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com Re: Bitwise logical operations
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Jul 89 18:56:48 PDT
Received: from MINTAKA.LCS.MIT.EDU by life.ai.mit.edu (4.1/AI-4.10) id AB09360; Fri, 21 Jul 89 21:41:14 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa19173;
21 Jul 89 14:15 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Jul 89 14:15:00 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa19144;
21 Jul 89 14:10 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA04362; Fri, 21 Jul 89 14:10:45 EDT
Received: from Xerox.COM (xerox.com) by zurich.ai.mit.edu; Fri, 21 Jul 89 14:07:40 edt
Received: from Semillon.ms by ArpaGateway.ms ; 21 JUL 89 10:45:20 PDT
Date: Fri, 21 Jul 89 10:47:14 PDT
From: Pavel.pa@xerox.com
Subject: Re: Bitwise logical operations
In-Reply-To: <8907202301.AA23454@mojave.Stanford.EDU>
To: rrrs-authors@zurich.ai.mit.edu
Message-Id: <890721-104520-3334@Xerox>
I strongly support Jonathan's bitwise logical operations proposal. I've
missed having these more than once.
Pavel
∂21-Jul-89 2101 @mc.lcs.mit.edu,@life.ai.mit.edu:jmiller@crl.dec.com Regularization of list, vector, and string procedures
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Jul 89 21:01:22 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA10197; Fri, 21 Jul 89 23:47:21 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa20822;
21 Jul 89 16:33 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Jul 89 16:16:16 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa20419;
21 Jul 89 16:10 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA05746; Fri, 21 Jul 89 16:09:43 EDT
Received: from decwrl.dec.com ([16.1.0.1]) by zurich.ai.mit.edu; Fri, 21 Jul 89 16:06:27 edt
Received: from crl.crl.dec.com by decwrl.dec.com (5.54.5/4.7.34)
id AA12047; Fri, 21 Jul 89 07:08:04 PDT
Received: from crl.crl.dec.com by decwrl.dec.com (5.54.5/4.7.34)
for rrrs-authors@zurich.ai.mit.edu; id AA12047; Fri, 21 Jul 89 07:08:04 PDT
Received: by crl.crl.dec.com (5.57/Ultrix2.4-C)
id AA13877; Fri, 21 Jul 89 09:38:41 EDT
Date: Fri, 21 Jul 89 09:30:45 EDT
From: jmiller@crl.dec.com
Message-Id: <8907211330.AA00412@peanut.DEC.COM>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@zurich.ai.mit.edu, Scheme-Standard@wheaties.ai.mit.edu
In-Reply-To: 20-Jul-89 1132 PDT's message of Fri, 21 Jul 89 06:47:31 EDT <8907211047.AA13726@crl.crl.dec.com>
Subject: Regularization of list, vector, and string procedures
Reply-To: JMiller@crl.enet.dec.com
COMMENTS PRIMARILY TO THE RRRS-AUTHORS LIST
I prefer to remain relatively silent on this mailing list, and send
mail only when it is something I feel strongly about, or is something
that I feel I should handle wearing my IEEE co-editor hat. (Someone
asked why there wasn't more comment on the content of the list; that's
my justification.)
As co-editor of the IEEE draft standard, I'd like to mention a
discussion that occurred earlier this week among the editors:
For virtually every data type mentioned in a procedure header line in
R4RS there is either an existing predicate in the language (string?
for string, vector? for vector, rational? for q_{n}, etc.) or a
trivial piece of code (like (lambda (k) (and (integer? k) (exact? k)
(positive? k))) for k_{n}). Not so for (proper) lists referred to as
"list" in the header line. It was our intention to have P1178 make
this connection explicit, whether or not R4RS chooses to do so, and
the missing predicate for proper lists causes a problem.
We had not planned to ask RNRS to change to add such a test. But
someone else has, so I'd like to support the addition of the predicate
LIST? that tests for proper lists. I don't mind if you call it
PROPER-LIST?, but I prefer the other name, especially since the
language of the report is very clear about the definition of a list,
and it excludes both cdr-circularity and dotted tails. Another
predicate might be of interest to RnRS (NOT-TAIL-CIRCULAR? or some
such) but you won't hear me agitating to have that added to the IEEE
proposal.
On another point, but still wearing my co-editor hat: I can't agree
with Pavel about keeping R4RS open. Let's simply take John Ramsdell's
list and agree that the Snowbird issues constitute R4RS (that's what
the meeting was for, anyway) and start NOW on R5RS issues, too: those
in John's Post Snowbird and (I don't like the name) Post R4RS list.
Let's aim for R5RS in about one year or so, and try to keep the
language alive by agreeing on changes and issuing reports frequently.
COMMENT TO BOTH RRRS-AUTHORS and SCHEME-STANDARD LISTS
Finally, as co-editor, I'd like to poll both mailing lists about one
of the many items that appeared in the GLS/Alan/cph mail about
numbers. Guy did a wonderful job restating my qualms (expressed at
the last IEEE meeting) about max/min. His observation explains my
objection to Will's assertion that their omission from the version of
Scheme used in his class last year was a trivial issue. There are
two, equally reasonable (in my opinion), interpretations of the MAX
and MIN operations.
(a) They are selectors from a set of numbers and thus there is
a legitimate expectation that (memq (max <set>) <set>) ==>
#t. (Yes, I DO mean memq not memv.)
(b) MAX and MIN are well-defined mathematical operations on a
set of numbers and hence the "contagious inexactness" rule
applies. In this case, (memv (max <set>) <set>) need not
be true due to implementation restrictions that make it
impossible to represent the (inexact) result with
sufficient accuracy for the result to be = to the (exact)
element from which it was derived.
Using the former concept, our definition of the Scheme functions would
need to be modified, but the argument in favor of the name change to
SUP/INF is inappropriate. Using the latter concept, there is an
argument that SUP/INF are superior names for what is actually
happening (based on the observation that SUP and INF of a set may
return limit elements that are not members of the set).
Can I have an informal show of hands? Please vote:
(1) Keep the names MAX and MIN, and make the semantics be
selector-like.
(2) Change the names to SUP and INF, and leave the semantics.
(3) Provide all 4 names and both semantics.
(4) Other.
If your answer depends on whether you are voting on a change to
R3.95RS or to P1178, please indicate.
--Jim Miller
P.S. -- In writing the above, I discovered a question I should be able
to answer but can't. First, notice that (max <set>) under
interpretation (b) (the current one) may signal an error even when all
elements of the set are real numbers -- due to the same implementation
restrictions. Question: are there real numbers that cause errors when
compared using < and so forth? I can't quite tell from reading
R3.95RS or P1178. Perhaps it is related to the requirement for
transitivity?
∂21-Jul-89 2104 @mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com Fluid binding
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Jul 89 21:03:54 PDT
Received: from gang-of-four.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AB10203; Fri, 21 Jul 89 23:50:32 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22110;
21 Jul 89 18:23 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Jul 89 18:23:18 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa22103;
21 Jul 89 18:21 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA07629; Fri, 21 Jul 89 18:21:07 EDT
Received: from sde.hp.com (sde.hp.com) by zurich.ai.mit.edu; Fri, 21 Jul 89 18:18:00 edt
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.6b/SES42.42) id AA22658; Fri, 21 Jul 89 15:20:44 pdt
Message-Id: <8907212220.AA22658@sde.hp.com>
Received: by hpesogg; Fri, 21 Jul 89 13:58:04 pdt
Date: Fri, 21 Jul 89 13:58:04 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Pavel.pa@xerox.com's message of Thu, 20 Jul 89 12:01:25 PDT <890720-200715-1255@Xerox>
Subject: Fluid binding
Reply-To: jinx%hpesogg@sde.hp.com
Fascinating; your perspective is completely opposite to mine. You ask,
``In the absence of FLUID-LET, what is the difference between your fluids
and 1-slot records?'' The answer, clearly, is ``nothing''. But FLUID-LET
is the whole issue, isn't it? You perceive my interpretation in terms of a
fluid environment as ``a lot of hair'', but it seems to me this idea os
``temporary/isolated contents'' is considerably hairier. In particular,
FLUID-LET in your interpretation is a side-effect that must carefully be
un-done or re-done whenever control leaves or re-enters the body of the
form. This seems very messy to me, conceptually; I shudder to think how it
would look when added to the formal semantics. A fluid environment, on the
other hand, is another instance of a well-understood concept. It is
essentially trivial to add it to the formal semantics, and under that
conception, FLUID-LET is no more a side-effect than LET.
Your argument is like saying that COND is "bad" because it is hard to
implement in the semantics. I don't care about writing directly in
the semantics when the construct can be provided conveniently by user
code.
Your model conceptually needs modification of the formal semantics,
while mine can be implemented trivially in a page of code. Which is
simpler?
I don't believe in cluttering up the semantics when the same
functionality can be provided as efficiently by user code.
∂21-Jul-89 2316 @mc.lcs.mit.edu:Alan@REAGAN.ai.mit.edu Numbers
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Jul 89 23:16:32 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA12005; Sat, 22 Jul 89 02:07:57 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa21114;
21 Jul 89 16:57 EDT
Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by MC.LCS.MIT.EDU 21 Jul 89 16:57:46 EDT
Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 239123; Fri 21-Jul-89 16:57:26 EDT
Date: Fri, 21 Jul 89 16:57 EDT
From: Alan Bawden <Alan@reagan.ai.mit.edu>
Subject: Numbers
To: gls@think.com
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: <8907181522.AA29642@verdi.think.com>
Message-Id: <19890721205725.0.ALAN@PIGPEN.AI.MIT.EDU>
Date: Tue, 18 Jul 89 11:22:03 EDT
From: gls@Think.COM (Guy Steele)
If, whenever someone doesn't like the consequences of the exactness rules,
we introduce a new procedure whose behavior he likes better, giving it the
old name and giving a new name to the old procedure, then ultimately what
good is exactness? In order to reap the benefits of exactness the user has
to write his program using a bunch of unfamiliar names (unfamiliar to
computer weenies) like INF and SUP.
The issue is not reaping the benefits of exactness; it is reaping the
benefits of inexactness. Let us not confuse the two.
Well actually, I expect that the tension between the benefits of exactness
and the benefits of inexactness is the root of most disagreements about
(in)exactness. The benefits of exactness are error checking. When I write
(vector-ref v (/ (* n (+ 1 n)) 2))
I know that, independent of the characteristics of arithmetic in my Scheme
implementation, I will be referencing the same element of the vector as
long as VECTOR-REF doesn't signal an error. If the multiplication
overflows the range of exact integers in some implementation and returns an
inexact, then the division will return an inexact as well, and then
VECTOR-REF will signal an error. Of course I give up this benefit of
exactness whenever I call a numeric predicate (and the manual takes pains
to warn me about this). The proposal is to abandon this benefit for MAX
and MIN as well.
(If I was being a real purist trouble maker, I would propose that the
predicates should behave just like VECTOR-REF, and signal an error when
given an inexact argument; then I would propose a parallel family of
"inexact numeric predicates" (PROBABLY-<, PROBABLY-=, PROBABLY-INTEGER?,
PROBABLY-ODD?, etc.) that would compare both exact and inexact numbers.)
The benefits of inexactness are that certain numerical questions can be
answered that would be very difficult to answer otherwise. (Although it
sometimes takes a numerical analyst to demonstrate that the answer really
is -correct-.) I don't see that the benefits of inexactness are enhanced
(or degraded) by making MIN and MIX unsafe.
..., then let me point out that Scheme weenies are vastly outnumbered
by C weenies, and every C weenie has the formula
#define max(x,y) ((x) > (y)) ? (x) : (y)
engraved in his little weenie brain. See? MAX really is a conditional.
Sure is. So much of a conditional that it even evaluates the expression
that returns the larger result -twice-! So I guess to a C weenie, MAX is
more like IF than +.
[About FLOOR, etc.:]
... if the inexactness is down at the level that you can be sure that
the integer result is exact (say you know the argument to within .001
and it is well away from being an integer or half-integer, as the case
may be), then return an exact result; otherwise return an inexact
result (but note that the uncertainty of the result may be relatively
much, much larger than the uncertainty of the input).
Right. Of course in the usual floating point implementation of inexact
numbers, the precision isn't represented explicitly (it exists only in the
mind of the numerical analyst who wrote the program), so FLOOR can't do
this. But certainly for other kinds of inexact implementations, such as
intervals or continued fractions, having FLOOR perform this kind of
analysis is perfectly reasonable, and does allow you to sometimes return an
exact result given inexact arguments.
... It seems to me that the assumption that users will be naive is
the foundation of the art of programming language design....
IBM has touted ACRITH as a system that, by using high precision and
interval arithmetic, will save you from all possible ills. See issues of
ACM SIGNUM for descriptions of why it actually loses horribly in many
cases. I suspect that inexactness as currently treated by Scheme is
no panacea.
Yeah, every time I mention interval arithmetic as an alternate
implementation for inexact numbers, someone volunteers to educate me about
what a lose intervals can be. Fortunately, I don't care how bad they can
be. I'm only interested in them as a "model" of something that obeys the
"axioms" of inexact numbers that -isn't- floating point.
But I don't see what the merits of interval arithmetic has to do with my
position on programmer naivete. I wasn't proposing interval arithmetic as
something that can help naive programmers. I was suggesting that
programmers will naively choose a function named "MIN" instead of a
function named "INF" in situations where they don't see that it can
possibly make any difference. And I claim that in situations where you
don't think it makes any difference, you probably want the function that
properly propogates inexactness.
Quick, without thinking hard, decide whether would you write
A. (vector-ref v (min max-index (/ (* n (+ 1 n)) 2)))
or
B. (vector-ref v (inf max-index (/ (* n (+ 1 n)) 2))) ?
I'll bet that most people would answer A. After all, MIN is the familiar
sounding name. You probably don't think you have to look MIN up in the
manual to remember what it does. You've always used MIN. MIN is what you
would have used in any other programming language. You probably don't even
-remember- INF unless you just happened to look at the manual.
Now suppose you have an implementation with 32-bit integers for exacts and
floating point inexacts. If MAX-INDEX is 2148565200 (your implementation
supports very big vectors!) and N is 65552, then
(* n (+ 1 n)) ==> 4297130256
which doesn't fit in 32 bits. The closest floating point approximation
(assuming a 24-bit mantissa) happens to be 4297130496.0, which is -larger-
than the correct value. Thus
(/ (* n (+ 1 n)) 2) ==> 2148565248.0
And so (assuming MIN and INF behave as proposed):
A. (min max-index (/ (* n (+ 1 n)) 2)) ==> 2148565200
while
B. (inf max-index (/ (* n (+ 1 n)) 2)) ==> <some inexact>
yet the correct exact answer (obtained in an implementation where the * did
not overflow) would be 2148565128. Thus people who chose A will blindly
access the wrong element of the vector, while people who chose B will have
an error signaled by VECTOR-REF. People who chose A have a bug in their
code, while people who chose B do not.
Gee, Alan, this is fun! Best flame I've had this year.
!
∂21-Jul-89 2322 @mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com Re: Fluid binding
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Jul 89 23:22:40 PDT
Received: from gang-of-four.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AB12020; Sat, 22 Jul 89 02:11:36 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22325;
21 Jul 89 18:47 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Jul 89 18:47:20 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa22291;
21 Jul 89 18:42 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA07856; Fri, 21 Jul 89 18:41:56 EDT
Received: from Xerox.COM (xerox.com) by zurich.ai.mit.edu; Fri, 21 Jul 89 18:38:53 edt
Received: from Cabernet.ms by ArpaGateway.ms ; 21 JUL 89 15:34:16 PDT
Date: Fri, 21 Jul 89 15:33:13 PDT
From: Pavel.pa@xerox.com
Subject: Re: Fluid binding
In-Reply-To: <8907212220.AA22658@sde.hp.com>
To: rrrs-authors@zurich.ai.mit.edu
Cc: Pavel.pa@xerox.com
Message-Id: <890721-153416-4384@Xerox>
Your argument is like saying that COND is "bad" because it is hard to
implement in the semantics. I don't care about writing directly in
the semantics when the construct can be provided conveniently by user
code.
COND isn't at all hard to describe in the formal semantics.
Your model conceptually needs modification of the formal semantics,
while mine can be implemented trivially in a page of code. Which is
simpler?
Huh? Even your last example, written using dynamic-wind, wasn't entirely
in user code; it relied upon two mysterious primitives whose semantics I'm
still not sure of. That ain't user code by my definition. If you can't
write an implementation in R4RS Scheme, without reference to mysterious
primitives with implementation-specific semantics, then I claim it has to
go into the formal semantics.
Pavel
∂21-Jul-89 2331 @mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com Regularization of list, vector, and string procedures
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Jul 89 23:31:39 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA12043; Sat, 22 Jul 89 02:17:13 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa25362;
21 Jul 89 23:23 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Jul 89 23:23:30 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa25308;
21 Jul 89 23:19 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA10079; Fri, 21 Jul 89 23:19:33 EDT
Received: from sde.hp.com (sde.hp.com) by zurich.ai.mit.edu; Fri, 21 Jul 89 23:16:27 edt
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.6b/SES42.42) id AA28419; Fri, 21 Jul 89 20:19:07 pdt
Message-Id: <8907220319.AA28419@sde.hp.com>
Received: by hpesogg; Fri, 21 Jul 89 20:11:21 pdt
Date: Fri, 21 Jul 89 20:11:21 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: JMiller@crl.enet.dec.com
Cc: Pavel.pa@xerox.com, rrrs-authors@zurich.ai.mit.edu,
Scheme-Standard@wheaties.ai.mit.edu
In-Reply-To: jmiller@crl.dec.com's message of Fri, 21 Jul 89 09:30:45 EDT <8907211330.AA00412@peanut.DEC.COM>
Subject: Regularization of list, vector, and string procedures
Reply-To: jinx%hpesogg@sde.hp.com
Using the former concept, our definition of the Scheme functions would
need to be modified, but the argument in favor of the name change to
SUP/INF is inappropriate. Using the latter concept, there is an
argument that SUP/INF are superior names for what is actually
happening (based on the observation that SUP and INF of a set may
return limit elements that are not members of the set).
Can I have an informal show of hands? Please vote:
(1) Keep the names MAX and MIN, and make the semantics be
selector-like.
(2) Change the names to SUP and INF, and leave the semantics.
(3) Provide all 4 names and both semantics.
(4) Other.
If your answer depends on whether you are voting on a change to
R3.95RS or to P1178, please indicate.
I assume that 2 means that only SUP and INF are to be provided, and
that they are not guaranteed to return an eqv? element of the set.
If so, my preferences (in this order) are
2
3
1
P.S. -- In writing the above, I discovered a question I should be able
to answer but can't. First, notice that (max <set>) under
interpretation (b) (the current one) may signal an error even when all
elements of the set are real numbers -- due to the same implementation
restrictions. Question: are there real numbers that cause errors when
compared using < and so forth? I can't quite tell from reading
R3.95RS or P1178. Perhaps it is related to the requirement for
transitivity?
It obviously depends on the implementation. An important thing to
notice (for implementors), however, is that it is not hard to compare
a bignum and a flonum without coercing one to the other. Thus the
comparison predicates need not error out when either argument can't be
cast to the form of the other, they just have to be clever.
∂23-Jul-89 0001 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #167
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Jul 89 00:01:19 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA18719; Sun, 23 Jul 89 02:20:40 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa07035;
23 Jul 89 0:08 EDT
Date: 23 JUL 89 00:06:13 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #167
To: Scheme@mc.lcs.mit.edu
Reply-To: Scheme@mc.lcs.mit.edu
Message-Id: <8907230008.aa07035@mintaka.lcs.mit.edu>
Scheme Digest #167 23 JUL 89 00:06:13 EDT
Today's Topics:
Cscheme posting
----------------------------------------------------------------------
Date: 19 Jul 89 13:54:30 GMT
From: Ross Judson <jarvis.csri.toronto.edu!utgpu!utzoo!dciem!nrcaer!sce!cognos!rossj@rutgers.edu>
Subject: Cscheme posting
Message-Id: <6592@cognos.UUCP>
As I understand it, Cscheme is a free (I hope!) implementation of
the scheme language. A month or two ago I read that somebody planned on
posting the most recent version. Has this been done? What's the status?
Unfortunately, I am unable to ftp, and, due to mailer screwups, unable to
mail out of this site at all. So posting is the only way I'll see it.
Does anybody from Ottawa or the region have it? I'd like to get in
touch if you do.
--
uucp - uunet!mitel!sce!cognos!rossj |people hate the generator
arpa/internet - rossj%cognos.uucp@uunet.uu.net |but love to light up the sky
------------------------------
End of Scheme Digest
********************
∂24-Jul-89 0904 @mc.lcs.mit.edu,@gateway.think.com:gls@think.com Numbers
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 24 Jul 89 09:04:45 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA29460; Mon, 24 Jul 89 11:54:48 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22178;
24 Jul 89 11:46 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 24 Jul 89 11:45:39 EDT
Received: from Gateway.Think.COM by mintaka.lcs.mit.edu id aa22154;
24 Jul 89 11:44 EDT
Received: from fafnir.think.com by Think.COM; Mon, 24 Jul 89 11:44:57 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Mon, 24 Jul 89 11:42:54 EDT
Received: by verdi.think.com; Mon, 24 Jul 89 11:42:50 EDT
Date: Mon, 24 Jul 89 11:42:50 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8907241542.AA09125@verdi.think.com>
To: Alan@reagan.ai.mit.edu
Cc: gls@think.com, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Alan Bawden's message of Fri, 21 Jul 89 16:57 EDT <19890721205725.0.ALAN@PIGPEN.AI.MIT.EDU>
Subject: Numbers
Date: Fri, 21 Jul 89 16:57 EDT
From: Alan Bawden <Alan@reagan.ai.mit.edu>
Quick, without thinking hard, decide whether would you write
A. (vector-ref v (min max-index (/ (* n (+ 1 n)) 2)))
or
B. (vector-ref v (inf max-index (/ (* n (+ 1 n)) 2))) ?
I'll bet that most people would answer A. After all, MIN is the familiar
sounding name. You probably don't think you have to look MIN up in the
manual to remember what it does. You've always used MIN. MIN is what you
would have used in any other programming language. You probably don't even
-remember- INF unless you just happened to look at the manual.
Now suppose you have an implementation with 32-bit integers for exacts and
floating point inexacts. If MAX-INDEX is 2148565200 (your implementation
supports very big vectors!) and N is 65552, then
(* n (+ 1 n)) ==> 4297130256
which doesn't fit in 32 bits. The closest floating point approximation
(assuming a 24-bit mantissa) happens to be 4297130496.0, which is -larger-
than the correct value. Thus
(/ (* n (+ 1 n)) 2) ==> 2148565248.0
And so (assuming MIN and INF behave as proposed):
A. (min max-index (/ (* n (+ 1 n)) 2)) ==> 2148565200
while
B. (inf max-index (/ (* n (+ 1 n)) 2)) ==> <some inexact>
yet the correct exact answer (obtained in an implementation where the * did
not overflow) would be 2148565128. Thus people who chose A will blindly
access the wrong element of the vector, while people who chose B will have
an error signaled by VECTOR-REF. People who chose A have a bug in their
code, while people who chose B do not.
Depends on why I put the MIN in there. If I put it in precisely to
guard against indexing off the end of the vector when running in
broken implementations that think 32 bits is enough to count anything
interesting at all, then the program is doing its job, and MIN is
exactly what I wanted. (Then again, I might have written
(vector-ref v (if (odd? n) (* n (/ (+ 1 n) 2)) (* (/ n 2) (+ 1 n))))
to be really safe.)
--Guy
∂24-Jul-89 0945 @mc.lcs.mit.edu,@life.ai.mit.edu:mkatz@sesame.stanford.edu Regularization of list, vector, and string procedures
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 24 Jul 89 09:45:09 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA29912; Mon, 24 Jul 89 12:27:42 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22525;
24 Jul 89 12:18 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 24 Jul 89 12:18:19 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa22506;
24 Jul 89 12:15 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA29684; Mon, 24 Jul 89 12:15:28 EDT
Received: from life.ai.mit.edu (ai.mit.edu) by zurich.ai.mit.edu; Mon, 24 Jul 89 12:11:47 edt
Received: from sesame.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA29246; Mon, 24 Jul 89 11:33:28 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA22748; Mon, 24 Jul 89 08:29:18 PDT
Date: Mon, 24 Jul 89 08:29:18 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8907241529.AA22748@sesame.Stanford.EDU>
To: jinx%hpesogg@sde.hp.com
Cc: Pavel.pa@xerox.com, rrrs-authors@zurich.ai.mit.edu
In-Reply-To: "Guillermo J. Rozas"'s message of Fri, 21 Jul 89 04:55:30 pdt <8907211156.AA10576@sde.hp.com>
Subject: Regularization of list, vector, and string procedures
Date: Fri, 21 Jul 89 04:55:30 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
Reply-To: jinx%hpesogg@sde.hp.com
I'd prefer to avoid generic procedures at the lowest levels of Scheme.
Why not have LIST-APPLY, VECTOR-APPLY, and STRING-APPLY, by analogy with
LIST-LENGTH, VECTOR-LENGTH, and STRING-LENGTH etc?
Assuming that ``apply'' is initially bound to the same value as
``list-apply'', I don't object to this proposal. It will be amusing to see
if I ever find a use for either of ``vector-apply'' or ``string-apply''.
I don't see a point to STRING-APPLY or VECTOR-APPLY (except to be used
with STRING or VECTOR to copy a string or vector). I think we should
leave APPLY alone for the following reasons:
- Apply is not really an operation on lists. It is a hook into the
procedure calling mechanism of the language so that procedures with
arbitrary arity can be called with arbitrary numbers of arguments.
Applying to lists is traditional, although funny in the same way that
arbitrary arity procedures (procedures with dotted lambda lists) build
lists.
The right way to fix APPLY is not to generalize it along its spurious
direction, but to devise some way by which we can drop user data
structures altogether from this hook into the system, for example, by
designing an alternative based on procedures.
This solution would be fine with me. What is not acceptable from a symmetry
point of view is to leave things unchanged. Either apply must work using some
new form or there must be versions for each of the reasonable data types.
- The kind of manipulation where apply is used is more conveniently
done on lists than on any other data structures.
Is this claim that it is more convenient from the user's perspective or the
language implementors? Some evidence of either would be greatly appreciated.
It is also natural
to think of argument lists as lists, rather than vectors or strings.
Maybe to some people. I find this argument far from persuasive.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂24-Jul-89 0948 @mc.lcs.mit.edu:mkatz@sesame.stanford.edu Regularization of list, vector, and string procedures
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 24 Jul 89 09:47:49 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA29941; Mon, 24 Jul 89 12:30:58 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22653;
24 Jul 89 12:23 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 24 Jul 89 12:24:00 EDT
Received: from [128.52.32.80] by mintaka.lcs.mit.edu id aa22553;
24 Jul 89 12:19 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA29736; Mon, 24 Jul 89 12:19:01 EDT
Received: from life.ai.mit.edu (ai.mit.edu) by zurich.ai.mit.edu; Mon, 24 Jul 89 12:15:47 edt
Received: from sesame.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA29075; Mon, 24 Jul 89 11:25:10 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA22683; Mon, 24 Jul 89 08:18:30 PDT
Date: Mon, 24 Jul 89 08:18:30 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8907241518.AA22683@sesame.Stanford.EDU>
To: JMiller@crl.enet.dec.com
Cc: Pavel.pa@xerox.com, rrrs-authors@zurich.ai.mit.edu,
Scheme-Standard@wheaties.ai.mit.edu
In-Reply-To: jmiller@crl.dec.com's message of Fri, 21 Jul 89 09:30:45 EDT <8907211330.AA00412@peanut.DEC.COM>
Subject: Regularization of list, vector, and string procedures
Can I have an informal show of hands? Please vote:
I do not care about the semantics nearly so much as the names. (Yes, I know
this is a wierd position.) I feel that the names MAX and MIN should be bound
to functions with some reasonable semantics. Whether RNRS has SUP and INF in
addition due to nuances in the definitions is not very important to me. I
would like the niave user who does not care about these nuances to be able to
find the functions he/she needs (i.e., MAX and MIN) with the greatest ease
possible.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂24-Jul-89 1216 @mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@relay.cs.net,@tektronix.tek.com:kend@mrloog.la.tek.com Re: Regularization of apply; Show of hands
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 24 Jul 89 12:16:37 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA01776; Mon, 24 Jul 89 15:03:07 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa24635;
24 Jul 89 14:52 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 24 Jul 89 14:45:17 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa24476;
24 Jul 89 14:43 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA01423; Mon, 24 Jul 89 14:43:08 EDT
Received: from RELAY.CS.NET (relay.cs.net) by zurich.ai.mit.edu; Mon, 24 Jul 89 14:39:56 edt
Received: from tektronix.tek.com by RELAY.CS.NET id aa27237; 24 Jul 89 14:36 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
id AA07628; Mon, 24 Jul 89 11:38:03 PDT
Received: by dadla.LA.TEK.COM (5.51/6.24)
id AA08842; Mon, 24 Jul 89 11:32:05 PDT
Received: by mrloog.la.tek.com (1.2/7.1)
id AA14325; Mon, 24 Jul 89 11:37:00 pdt
Message-Id: <8907241837.AA14325@mrloog.la.tek.com>
To: rrrs-authors@zurich.ai.mit.edu, Scheme-Standard@wheaties.ai.mit.edu
Subject: Re: Regularization of apply; Show of hands
In-Reply-To: Your message of Mon, 24 Jul 89 08:18:30 PDT.
<8907241518.AA22683@sesame.Stanford.EDU>
Date: 24 Jul 89 11:36:56 PDT (Mon)
From: kend%mrloog.la.tek.com@relay.cs.net
> The right way to fix APPLY is not to generalize it along its spurious
> direction, but to devise some way by which we can drop user data
> structures altogether from this hook into the system, for example, by
> designing an alternative based on procedures.
I would prefer that APPLY be applicable only to multiple values. For
that matter, I favor multiple value rest arguments--dropping rest *lists*
altogether.
> --Jim Miller
> Can I have an informal show of hands? Please vote:
> (1) Keep the names MAX and MIN, and make the semantics be
> selector-like.
> (2) Change the names to SUP and INF, and leave the semantics.
> (3) Provide all 4 names and both semantics.
> (4) Other.
> If your answer depends on whether you are voting on a change to
> R3.95RS or to P1178, please indicate.
For both R3.95RS and P1178, I prefer SUP and INF. Max and Min should be
defined in the Yellow Pages as macros (when we get macros). I would not
object to adding definition (as selectors) MAN and MIN to R3.95RS. MAX
and MIN are obviously too radical for P1178 [and--assuming macros--can be
trivially implemented].
-Ken Dickey kend@mrloog.LA.TEK.COM
∂24-Jul-89 1255 @mc.lcs.mit.edu,@life.ai.mit.edu:Alan@REAGAN.ai.mit.edu Regularization of list, vector, and string procedures
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 24 Jul 89 12:55:42 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA02213; Mon, 24 Jul 89 15:39:55 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa25075;
24 Jul 89 15:29 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 24 Jul 89 15:29:40 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa25065;
24 Jul 89 15:26 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02076; Mon, 24 Jul 89 15:26:47 EDT
Received: from REAGAN.AI.MIT.EDU (reagan.ai.mit.edu) by zurich.ai.mit.edu; Mon, 24 Jul 89 15:23:25 edt
Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 239933; Mon 24-Jul-89 15:26:31 EDT
Date: Mon, 24 Jul 89 15:26 EDT
From: Alan Bawden <Alan@reagan.ai.mit.edu>
Subject: Regularization of list, vector, and string procedures
To: JMiller@crl.enet.dec.com
Cc: Pavel.pa@xerox.com, rrrs-authors@zurich.ai.mit.edu,
Scheme-Standard@wheaties.ai.mit.edu
In-Reply-To: <8907211330.AA00412@peanut.DEC.COM>
Message-Id: <19890724192626.3.ALAN@PIGPEN.AI.MIT.EDU>
Date: Fri, 21 Jul 89 09:30:45 EDT
From: jmiller@crl.dec.com
...
Can I have an informal show of hands? Please vote:
(1) Keep the names MAX and MIN, and make the semantics be
selector-like.
(2) Change the names to SUP and INF, and leave the semantics.
(3) Provide all 4 names and both semantics.
(4) Other.
I vote 4. There should be no procedures named SUP and INF. We should
have procedures named MIN and MAX that only return exact numbers given
exact arguments.
I guess that the fact that my opinion didn't even make your list of options
means that I'm not making myself clear.
If your answer depends on whether you are voting on a change to
R3.95RS or to P1178, please indicate.
My opinion applies to RnRS only.
∂24-Jul-89 1549 @mc.lcs.mit.edu:Alan@REAGAN.ai.mit.edu Numbers
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 24 Jul 89 15:49:37 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA04267; Mon, 24 Jul 89 18:33:54 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa26955;
24 Jul 89 18:31 EDT
Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by MC.LCS.MIT.EDU 24 Jul 89 18:32:10 EDT
Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 240033; Mon 24-Jul-89 18:31:20 EDT
Date: Mon, 24 Jul 89 18:31 EDT
From: Alan Bawden <Alan@reagan.ai.mit.edu>
Subject: Numbers
To: gls@think.com
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: <8907241542.AA09125@verdi.think.com>
Message-Id: <19890724223118.4.ALAN@PIGPEN.AI.MIT.EDU>
Date: Mon, 24 Jul 89 11:42:50 EDT
From: Guy Steele <gls@think.com>
Date: Fri, 21 Jul 89 16:57 EDT
From: Alan Bawden <Alan@reagan.ai.mit.edu>
...
And so (assuming MIN and INF behave as proposed):
A. (min max-index (/ (* n (+ 1 n)) 2)) ==> 2148565200
while
B. (inf max-index (/ (* n (+ 1 n)) 2)) ==> <some inexact>
yet the correct exact answer (obtained in an implementation where
the * did not overflow) would be 2148565128. Thus people who chose
A will blindly access the wrong element of the vector, while people
who chose B will have an error signaled by VECTOR-REF. People who
chose A have a bug in their code, while people who chose B do not.
Depends on why I put the MIN in there. If I put it in precisely to
guard against indexing off the end of the vector when running in broken
implementations that think 32 bits is enough to count anything
interesting at all, then the program is doing its job, and MIN is
exactly what I wanted....
No matter what gonzo behavior is proposed for MIN, you can -always- defend
the resulting behavior by saying "well, perhaps that's what I wanted".
Well, suppose it wasn't what I wanted. Suppose I was computing a histogram
of some sort. I might be pretty puzzled by the fact that bucket 2148565200
had so many entries. Or perhaps I wouldn't notice at all. Perhaps I
publish my results, and then someday somebody gets a lethal dose of
radiation as a result. See? I can make up stories too.
Out of frustration, I will now change my position.
1. I now propose that all the numeric predicates should signal an error
when given any inexact arguments. I propose a parallel family of numeric
predicates with names like "%=" and "%ODD?" that behave unsafely, as the
current numeric predicates do.
2. I propose that numeric functions, such as LOG and /, that can signal
errors at certain points in the domain of one of their arguments, -must-
signal an error if that argument is inexact. I propose to add a parallel
family of numeric functions with names like "%LOG" and "%/" that behave
unsafely, as the current numeric functions do. (For uniformity, we might
have both + and %+, even thought they behave identically.)
3. I propose to change the names of EXACT? and INEXACT? to be "%EXACT?"
and "%INEXACT?".
4. Finally, I propose we add %MIN and %MAX to compute the unsafe minimum
and maximum that seems so popular.
With these changes in place, Scheme would have the following property:
A program that does not contain a "%", will compute the same exact
numeric result in all Scheme implementations in which it doesn't signal
an error or return an inexact result.
(My proposal is actually stronger than necessary to insure this property.
In an implementations that use representations other than floating point
for inexacts, it may be possible to reliably answer questions such as
(< X Y) reliably, so an error need not be signaled in that case. I could
have simply proposed that implementations can do whatever they want, as
long as they don't violate that property.)
I realize that nobody will take me seriously on this. But nobody was
taking me seriously anyway.
∂25-Jul-89 1259 @mc.lcs.mit.edu,@gateway.think.com:gls@think.com Numbers
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 25 Jul 89 12:58:07 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA16380; Tue, 25 Jul 89 15:41:12 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa11442;
25 Jul 89 15:27 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 25 Jul 89 15:27:19 EDT
Received: from Gateway.Think.COM by mintaka.lcs.mit.edu id aa11396;
25 Jul 89 15:21 EDT
Received: from fafnir.think.com by Think.COM; Tue, 25 Jul 89 15:21:40 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Tue, 25 Jul 89 15:19:30 EDT
Received: by verdi.think.com; Tue, 25 Jul 89 14:23:01 EDT
Date: Tue, 25 Jul 89 14:23:01 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8907251823.AA27924@verdi.think.com>
To: Alan@reagan.ai.mit.edu
Cc: gls@think.com, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Alan Bawden's message of Mon, 24 Jul 89 18:31 EDT <19890724223118.4.ALAN@PIGPEN.AI.MIT.EDU>
Subject: Numbers
Date: Mon, 24 Jul 89 18:31 EDT
From: Alan Bawden <Alan@reagan.ai.mit.edu>
Date: Mon, 24 Jul 89 11:42:50 EDT
From: Guy Steele <gls@think.com>
Date: Fri, 21 Jul 89 16:57 EDT
From: Alan Bawden <Alan@reagan.ai.mit.edu>
...
And so (assuming MIN and INF behave as proposed):
A. (min max-index (/ (* n (+ 1 n)) 2)) ==> 2148565200
while
B. (inf max-index (/ (* n (+ 1 n)) 2)) ==> <some inexact>
yet the correct exact answer (obtained in an implementation where
the * did not overflow) would be 2148565128. Thus people who chose
A will blindly access the wrong element of the vector, while people
who chose B will have an error signaled by VECTOR-REF. People who
chose A have a bug in their code, while people who chose B do not.
Depends on why I put the MIN in there. If I put it in precisely to
guard against indexing off the end of the vector when running in broken
implementations that think 32 bits is enough to count anything
interesting at all, then the program is doing its job, and MIN is
exactly what I wanted....
No matter what gonzo behavior is proposed for MIN, you can -always- defend
the resulting behavior by saying "well, perhaps that's what I wanted".
No matter for what sensible reason I wrote "MIN" in my code instead
of "INF", you can -always- attack my claim that this example supports a
general rationale by saying, "No matter what gonzo behavior...."
:-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-)
Well, suppose it wasn't what I wanted. Suppose I was computing a histogram
of some sort. I might be pretty puzzled by the fact that bucket 2148565200
had so many entries. Or perhaps I wouldn't notice at all. Perhaps I
publish my results, and then someday somebody gets a lethal dose of
radiation as a result. See? I can make up stories too.
Well, if I were to examine the code and spot -either- a MIN or INF
that clipped the bucket number to 2148565200, I think I would be
led to reason about that code a little more closely...
--Guy
P.S. This is fun.
∂25-Jul-89 1454 @mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com Regularization of apply; Show of hands
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 25 Jul 89 14:54:03 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA17769; Tue, 25 Jul 89 17:33:52 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa13066;
25 Jul 89 17:24 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 25 Jul 89 17:23:24 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa12984;
25 Jul 89 17:20 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA17539; Tue, 25 Jul 89 17:20:23 EDT
Received: from sde.hp.com (sde.hp.com) by zurich.ai.mit.edu; Tue, 25 Jul 89 17:17:06 edt
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.6b/SES42.42) id AA05849; Tue, 25 Jul 89 14:20:02 pdt
Message-Id: <8907252120.AA05849@sde.hp.com>
Received: by hpesogg; Tue, 25 Jul 89 14:19:10 pdt
Date: Tue, 25 Jul 89 14:19:10 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: kend%mrloog.la.tek.com@relay.cs.net
Cc: rrrs-authors@zurich.ai.mit.edu, Scheme-Standard@wheaties.ai.mit.edu
In-Reply-To: kend%mrloog.la.tek.com@relay.cs.net's message of 24 Jul 89 11:36:56 PDT (Mon) <8907241837.AA14325@mrloog.la.tek.com>
Subject: Regularization of apply; Show of hands
Reply-To: jinx%hpesogg@sde.hp.com
Date: 24 Jul 89 11:36:56 PDT (Mon)
From: kend%mrloog.la.tek.com@relay.cs.net
> The right way to fix APPLY is not to generalize it along its spurious
> direction, but to devise some way by which we can drop user data
> structures altogether from this hook into the system, for example, by
> designing an alternative based on procedures.
I would prefer that APPLY be applicable only to multiple values. For
that matter, I favor multiple value rest arguments--dropping rest *lists*
altogether.
What do you mean by multiple values?
Do you mean something like LAMBDA*'s & pseudo-objects?
If you mean something along the more traditional lines, you have just
pushed the problem one level deeper, since your multiple value
receivers are also expressed in lambda notation and therefore you need
to have dotted lists.
∂25-Jul-89 1524 @mc.lcs.mit.edu,@life.ai.mit.edu:gls@think.com Regularization of apply; Show of hands
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 25 Jul 89 15:24:09 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA18275; Tue, 25 Jul 89 18:09:33 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa13466;
25 Jul 89 17:56 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 25 Jul 89 17:56:25 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa13445;
25 Jul 89 17:52 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA18030; Tue, 25 Jul 89 17:52:06 EDT
Received: from Think.COM ([131.239.2.1]) by zurich.ai.mit.edu; Tue, 25 Jul 89 17:48:51 edt
Received: from fafnir.think.com by Think.COM; Tue, 25 Jul 89 17:45:04 EDT
Received: from verdi.think.com by fafnir.think.com; Tue, 25 Jul 89 17:42:58 EDT
Received: by verdi.think.com; Tue, 25 Jul 89 17:42:53 EDT
Date: Tue, 25 Jul 89 17:42:53 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8907252142.AA04994@verdi.think.com>
To: jinx%hpesogg@sde.hp.com
Cc: kend%mrloog.la.tek.com@relay.cs.net, rrrs-authors@zurich.ai.mit.edu,
Scheme-Standard@wheaties.ai.mit.edu
In-Reply-To: Guillermo J. Rozas's message of Tue, 25 Jul 89 14:19:10 pdt <8907252120.AA05849@sde.hp.com>
Subject: Regularization of apply; Show of hands
Date: Tue, 25 Jul 89 14:19:10 pdt
From: Guillermo J. Rozas <jinx@hpesogg.hp.com>
Date: 24 Jul 89 11:36:56 PDT (Mon)
From: kend%mrloog.la.tek.com@relay.cs.net
> The right way to fix APPLY is not to generalize it along its spurious
> direction, but to devise some way by which we can drop user data
> structures altogether from this hook into the system, for example, by
> designing an alternative based on procedures.
I would prefer that APPLY be applicable only to multiple values. For
that matter, I favor multiple value rest arguments--dropping rest *lists*
altogether.
What do you mean by multiple values?
Do you mean something like LAMBDA*'s & pseudo-objects?
If you mean something along the more traditional lines, you have just
pushed the problem one level deeper, since your multiple value
receivers are also expressed in lambda notation and therefore you need
to have dotted lists.
This strikes me as almost certainly a reference to the "rest values"
described by Dybvig and Hieb in Proc. 1988 ACM Conf. Lisp and Functional
Programming. Note that while that paper speaks of rest variables,
it does not state in so many words that the collection of values
associated with such a variables constitutes any sort of object,
pseudo- or otherwise.
By the way, I think that this idea in lambda* has much to recommend it.
(Then again, the ever-mythical "sufficiently smart compiler" ought to
be able to use data flow analysis to eliminate many, though not all,
uses of rest-lists...)
--Guy
∂25-Jul-89 1909 @mc.lcs.mit.edu,@life.ai.mit.edu:KMP@stony-brook.scrc.symbolics.com INF/SUP/MIN/MAX, LIST?/PROPER-LIST?, APPLY
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 25 Jul 89 19:08:48 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA20223; Tue, 25 Jul 89 21:39:21 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa15563;
25 Jul 89 21:08 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 25 Jul 89 20:55:21 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa14514;
25 Jul 89 19:36 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA19155; Tue, 25 Jul 89 19:36:01 EDT
Received: from STONY-BROOK.SCRC.Symbolics.COM (stony-brook.scrc.symbolics.com) by zurich.ai.mit.edu; Tue, 25 Jul 89 19:32:47 edt
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 631474; 25 Jul 89 19:06:48 EDT
Date: Tue, 25 Jul 89 19:06 EDT
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Subject: INF/SUP/MIN/MAX, LIST?/PROPER-LIST?, APPLY
To: RRRS-Authors@zurich.ai.mit.edu
In-Reply-To: <8907211330.AA00412@peanut.DEC.COM>
Message-Id: <19890725230639.8.KMP@BOBOLINK.SCRC.Symbolics.COM>
As most of you know, I don't use Scheme regularly. But I have in the
past and might again, and I do care about it. I offer my advice as that
of an informed observer and potential future user...
- I have advocated a PROPER-LIST? function in T ever since
its creation. It was there for a while, and perhaps later
removed. I have no idea what its current state is. I
definitely feel strongly that writing a circularity-checker
is easy to do but not everyone knows how to do it. It's
easy to interleave circularity checking with the atom/null
check that PROPER-LIST? will do, to give a nice overall effect.
I strongly favor the introduction of PROPER-LIST?
If the name LIST? were introduced, I feel quite strongly
that it should parallel what LISTP does in Lisp because there
are too many people who've gone back and forth and it was
just too confusing going from Maclisp's LISTP to CL's LISTP
without having that incompatibility hassle introduced all over
again. I think that for people who go to care to construct
only proper lists, CL's LISTP is the right cross between
efficiency and reliability.
If everyone will not agree to put LIST? in as a synonym for
(LAMBDA (X) (OR (NULL? X) (PAIR? X))), then everyone should
agree to leave it out and go for PROPER-LIST? (on which I think
we can agree about the definition) so that implementations that
want to put LIST? in compatibly can do so.
As a -complete- aside, I would be quite happy to also see a
library function which would be described in CL notation by
CIRCULAR? list &KEY (path #'CDR) (end-test #'NULL?)
[and which you could set up argument-wise however you liked
in Scheme], but I don't expect there to be a enough support
for that to bother pursuing it at this late date.
- With regard to MAX/MIN and INF/SUP, let me just say that there
are two approaches to designing a language: you can figure out
what you can understand/implement and then provide that, or you
can figure out what users want/need and try to figure a way to
provide that.
If users were crying out for INF/SUP, then I think you should
consider providing it, but I've never heard anyone ask for it.
I have heard them ask for MAX/MIN and just plain think they
should be provided. The importance of returning an EQV? value
is that I may be doing selection from a list of items, and I may
be planning to later try to use MEMBER? or ASSOC? some such to
later find the element again in the list. If MAX/MIN `destroys'
the identity of the argument and gives me back something which
isn't really the same, then my algorithms may fail. I'm big on
object identity and <<uh, what's the opposite-- little??>> on
things that casually disregard it.
In my opinion, the whole INF/SUP debate comes down to a haughty
disregard on the part of some designers for a clearly expressed
need on the part of users. I've not been convinced by any discussion
I've seen that the MAX/MIN users are calling for is impossible to
provide. What it sounds like to me is that the implementors are
busy building a wall that is going to impede entry into the Scheme
community because potential users are going to have to be even
more mathematically anal than they already have to be in order to
feel comfortable with what's provided. When people talk about max
in English, they say "give me the maximum of" not "a maximum of".
I think most "normal people" (like my mom or J. random programmer
who hasn't got a doctorate in advanced degree in math) expect a
uniquely determined result which is IN the initial set.
I think we should offer that. If we offer something else, that's fine.
But don't do it on MAX. And don't be so stubborn that you can't provide
the MAX that 99.9% of your users are clearly asking for.
Note: I personally wouldn't mind if MAX -failed- (reliably signalled
an error or however you scheme guys say that) in the case where there was
a potential problem due to exactness. I wouldn't mind if it was required
that all arguments be exact or that all be inexact. I only care that if
I do get back a result, it's described by the rules that I intuitively use.
But I suspect others would find this too tedious, and anyway, it's
inconsistent with the idea that <, etc. can compare exact and inexact numbers.
After all, there's a fundamental problem underlying all inexact comparisons
that depending on -how- inexact two numbers are, the one which -appears- less
may not really be. Once you've opened that door, it's not clear where to
start drawing the line. So given all that, I think the right thing is just
to assume every number is correct locally within the operation, and then
to just return the `biggest' number with its original exactness and leave
it at that.
- I think APPLY should be left alone. It should do the job needed in order
to describe how to apply functions in forms. Since lists are all that's
needed to express forms, I think they're all that's needed in order to
describe applcication.
APPLY definitely should not be extended to vecotrs unless you make
it so that vectors are valid forms for evaluation (i guess with the
operator in slot 0 and the args in successive slots), but i don't
see any point to that either. It just reduces error checking.
I don't think extending apply to deal with multiple values is a good
idea for pretty much the same reason. Also because I think the idea
of turning APPLY (currently a normal function) into something that
could grok multiple values is a good change. If you want a new special
form (or keyword, i guess you call them), call it something other than
APPLY so as not to confuse the whole universe. If you call it something
else, I don't mind having it around--but then I don't think it should
bother hacking lists... and I'd still keep APPLY, both for historical
reasons and because it's useful even now.
Do not undervalue the importance of leaving holes in your syntactic
space. The more things you make "defined", the less robust your
language becomes because everything means something. The problem is
that the only chance you have to catch a programmer babbling is when
he says something so obviously wrong that you can flag it without
knowing the context. Unless you have a compelling reason to make
things that are currently "obviously wrong" into "meaningful", then
you should think twice about giving up your freedom to recognize
problems. This is -especially- true in a language like Scheme which
has such an underdeveloped notion of error handling and where users can
(at least, if the spec is all they have to go on) really rely on nothing
much to catch them if they venture beyond the clearly specified range
of what they're -supposed to- have done.
I hope these comments are of help in resolving the latest flurry of
conflicts.
By the way, one thing the CL community has done well which the Scheme community
has done poorly, is to document in a modular fashion all the design rationales
for ongoing changes to the language so that they aren't doomed to repeat the
same arguments over and over again. It would be nice if the Scheme community
started to move toward a similar bookkeeping strategy. Many of these arguments
hit me with a real sense of deja vu which it seems to me could have been
avoided.
∂25-Jul-89 1915 @mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com Regularization of apply (long)
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 25 Jul 89 19:15:23 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA20399; Tue, 25 Jul 89 22:02:08 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa15872;
25 Jul 89 21:24 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 25 Jul 89 20:56:38 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa14805;
25 Jul 89 20:03 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA19331; Tue, 25 Jul 89 20:03:31 EDT
Received: from sde.hp.com (sde.hp.com) by zurich.ai.mit.edu; Tue, 25 Jul 89 20:00:16 edt
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.6b/SES42.42) id AA10241; Tue, 25 Jul 89 17:02:58 pdt
Message-Id: <8907260002.AA10241@sde.hp.com>
Received: by hpesogg; Tue, 25 Jul 89 17:02:14 pdt
Date: Tue, 25 Jul 89 17:02:14 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: gls@think.com
Cc: kend%mrloog.la.tek.com@relay.cs.net, rrrs-authors@zurich.ai.mit.edu,
Scheme-Standard@wheaties.ai.mit.edu
In-Reply-To: Guy Steele's message of Tue, 25 Jul 89 17:42:53 EDT <8907252142.AA04994@verdi.think.com>
Subject: Regularization of apply (long)
Reply-To: jinx%hpesogg@sde.hp.com
What do you mean by multiple values?
Do you mean something like LAMBDA*'s & pseudo-objects?
If you mean something along the more traditional lines, you have just
pushed the problem one level deeper, since your multiple value
receivers are also expressed in lambda notation and therefore you need
to have dotted lists.
This strikes me as almost certainly a reference to the "rest values"
described by Dybvig and Hieb in Proc. 1988 ACM Conf. Lisp and Functional
Programming. Note that while that paper speaks of rest variables,
it does not state in so many words that the collection of values
associated with such a variables constitutes any sort of object,
pseudo- or otherwise.
kend's comment may well have been a reference to Dybvig and Hieb's
"rest values", which is precisely what I was asking.
Although I agree that there are interesting issues in lambda*, I think
that lambda* mixes up too many concepts and imposes implementation
restrictions that I'm not sure I like.
I envision something more primitive, and completely different. I
think that using lists, vectors, or special values to collect and pass
arbitrary numbers of arguments is spurious. Specific data structures
should be introduced by the user according to convenience or intent.
The arbitrary arity mechanism in the language should not be based on
arbitrary data aggragates at all, but on something more primitive, and
procedures (I think) are a good choice.
As a "proof of concept" I will present an example, which in no way
should be taken as a proposal for RnRs, but merely as a hint of what I
would like to see.
Consider the two "primitives" SUPPLY-ARGUMENTS and
MAKE-ARGUMENTS-COLLECTOR. Sample implementations are provided below
in terms of APPLY and "dot notation".
SUPPLY-ARGUMENTS is analogous to APPLY. It is a mechanism for
suppliying arguments to a procedure without knowing at programming
time exactly how many arguments are being supplied. SUPPLY-ARGUMENTS
coroutines with the argument supplier, which provides one argument at
a time. SUPPLY-ARGUMENTS calls all of them, and eventually invokes
the procedure on all the arguments collected.
MAKE-ARGUMENTS-COLLECTOR is analogous in intent to "dot notation". It
is a mechanism for constructing a procedure that accepts any number of
arguments. The essential idea is that collecting any number of arguments
is a reduction process with a null-value (the terminator) and a "combiner"
which combines the current argument with the combination of the remaining
arguments. There is also a "wrapper" which allows some further processing
after all the arguments have been processed.
These "primitives" are somewhat clumsy and I have not thought about
their native implementation carefully, but are a relatively good way
to describe procedures of arbitrary arity without reference to
individual data structures.
Sample implementation in terms of apply and "dot notation":
;;; New "primitives"
(define (supply-arguments procedure supplier)
(define (collect-loop l supplier)
(supplier
(lambda (next new-supplier)
(collect-loop (cons next l)
new-supplier))
(lambda ()
(APPLY procedure (reverse l)))))
(collect-loop '() supplier))
(define (make-arguments-collector wrapper combiner terminator)
(lambda ARG-LIST
(define (process l)
(if (null? l)
(terminator)
(combiner (car l)
(process (cdr l)))))
(wrapper (process ARG-LIST))))
Examples of their use:
;; This is the traditional 2-argument apply.
(define (invoke-on-list procedure l)
(define (supply l collect-next end)
(if (null? l)
(end)
(collect-next (car l)
(lambda (next-collector next-end)
(supply (cdr l) next-collector next-end)))))
(supply-arguments
procedure
(lambda (collect end)
(supply l collect end))))
(define (invoke-on-vector procedure v)
(define (supply i collect-next end)
(if (>= i (vector-length v))
(end)
(collect-next (vector-ref v i)
(lambda (next-collector next-end)
(supply (1+ i) next-collector next-end)))))
(supply-arguments
procedure
(lambda (collect end)
(supply 0 collect end))))
(define nary-+
(make-arguments-collector (lambda (x) x)
+
(lambda () 0)))
(define count-args
(make-arguments-collector (lambda (x) x)
(lambda (x rest)
(1+ rest))
(lambda () 0)))
(define list
(make-arguments-collector (lambda (x) x)
cons
(lambda () '())))
(define vector
(make-arguments-collector list->vector
cons
(lambda () '())))
(define cons*
(let ((tag (cons 'cons*-tag '())))
(make-arguments-collector
(lambda (result)
(if (eq? result tag)
(error "cons*: No arguments supplied")
result))
(lambda (new tail)
(if (eq? tail tag)
new
(cons new tail)))
(lambda () tag))))
;; This is the full-fledged apply.
(define apply
(make-arguments-collector
(lambda (result)
(case (car result)
((none-provided)
(error "apply: No arguments supplied"))
((one-provided)
((cdr result)))
(else
(invoke-on-list (cadr result)
(cddr result)))))
(lambda (new tail)
(case (car tail)
((none-provided)
(cons 'one-provided new))
(else
(cons 'normal
(cons new (cdr tail))))))
(lambda ()
(cons 'none-provided '()))))
∂25-Jul-89 2003 @mc.lcs.mit.edu:Alan@REAGAN.ai.mit.edu Numbers
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 25 Jul 89 20:03:33 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA20760; Tue, 25 Jul 89 22:53:21 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa16904;
25 Jul 89 22:41 EDT
Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by MC.LCS.MIT.EDU 25 Jul 89 22:42:08 EDT
Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 240964; Tue 25-Jul-89 22:41:20 EDT
Date: Tue, 25 Jul 89 22:41 EDT
From: Alan Bawden <Alan@reagan.ai.mit.edu>
Subject: Numbers
To: gls@think.com
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: <8907251823.AA27924@verdi.think.com>
Message-Id: <19890726024117.0.ALAN@PIGPEN.AI.MIT.EDU>
Date: Tue, 25 Jul 89 14:23:01 EDT
From: gls@Think.COM (Guy Steele)
...
Well, if I were to examine the code and spot -either- a MIN or INF
that clipped the bucket number to 2148565200, I think I would be
led to reason about that code a little more closely...
But INF will -never- clip to the wrong bucket! That's the whole point of
the example! INF doesn't shaft you by returning an exact number when it
doesn't know the answer exactly, it return an inexact number, and then
VECTOR-REF signals an error. With INF, you learn of a limitation in the
arithmetic of your Scheme implementation (so that perhaps you can rewrite
your code in the clever way you suggested the other day). With MIN, your
program just references the wrong element of the vector.
(No need to point out that I have again returned to assuming that
2148565200 is the "wrong" bucket. Again, if what MIN does just happens to
do what you really wanted, whatever that may be, then of course you will
have no cause to complain about its behavior. But assuming that you put
that call to MIN/INF in there because you thought you were computing a
histogram, and you wanted to count all the huge values in the -last-
bucket, then 2148565200 is an error.)
∂26-Jul-89 0359 @mc.lcs.mit.edu,@life.ai.mit.edu:Alan@reagan.ai.mit.edu INF/SUP/MIN/MAX
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 26 Jul 89 03:59:19 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AB24395; Wed, 26 Jul 89 06:48:58 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa20216;
26 Jul 89 3:43 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 26 Jul 89 03:43:29 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa20187;
26 Jul 89 3:37 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA23380; Wed, 26 Jul 89 03:37:29 EDT
Received: from REAGAN.AI.MIT.EDU (reagan.ai.mit.edu) by zurich.ai.mit.edu; Wed, 26 Jul 89 03:34:15 edt
Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 240992; Wed 26-Jul-89 01:15:19 EDT
Date: Wed, 26 Jul 89 01:15 EDT
From: Alan Bawden <Alan@reagan.ai.mit.edu>
Subject: INF/SUP/MIN/MAX
To: KMP@stony-brook.scrc.symbolics.com
Cc: RRRS-Authors@zurich.ai.mit.edu
In-Reply-To: <19890725230639.8.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-Id: <19890726051514.2.ALAN@PIGPEN.AI.MIT.EDU>
Date: Tue, 25 Jul 89 19:06 EDT
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
...
If users were crying out for INF/SUP, then I think you should consider
providing it, but I've never heard anyone ask for it.
I have heard them ask for MAX/MIN and just plain think they should be
provided.
I've never heard users asking for the notion of exactness/inexactness at
all. Ask them what they want, and they will probably tell you that they
want IEEE floating point. As I have said before, I think it would be 100%
reasonable for Scheme to do what every other language does, and adopt some
reasonable set of rules for the behavior of floating point. Unfortunately,
Scheme decided to go in a different direction. Inexact numbers are not
just another name for floating point, so we have -already- decided to give
users something other than what they would ask for. What we are arguing
about here, are the -consequences- of that decision for the function MIN.
I was under the impression that the consistency of the language mattered,
not just what the users think they want before you have a chance to explain
the issues to them.
The importance of returning an EQV? value is that I may be
doing selection from a list of items, and I may be planning to later
try to use MEMBER? or ASSOC? some such to later find the element again
in the list. If MAX/MIN `destroys' the identity of the argument and
gives me back something which isn't really the same, then my algorithms
may fail. I'm big on object identity and <<uh, what's the opposite--
little??>> on things that casually disregard it.
I'd be interested in seeing examples of code that depends on the identity
of the value returned by MAX or MIN. I just checked through all of my
Scheme code, and I didn't find any instances in which it mattered.
Typically I found that the result was fed into a function like +, - or *.
Once the result was passed as the first argument to MAKE-STRING. In the
case of MAKE-STRING, having MAX return an inexact number when any argument
was inexact provides the kind of error checking I've been flaming to Steele
about. I'm a fan of object identity too, but not at the expense of
returning a incorrect result.
In my opinion, the whole INF/SUP debate comes down to a haughty
disregard on the part of some designers for a clearly expressed need on
the part of users.
I don't see anybody else here defending this point of view, so it must be
me who is being "haughty". Below, I apparently become "anal" and
"stubborn". I must say, it's more fun arguing with Steele.
I've not been convinced by any discussion I've seen
that the MAX/MIN users are calling for is impossible to provide. What
it sounds like to me is that the implementors are busy building a wall
that is going to impede entry into the Scheme community because
potential users are going to have to be even more mathematically anal
than they already have to be in order to feel comfortable with what's
provided. When people talk about max in English, they say "give me the
maximum of" not "a maximum of". I think most "normal people" (like my
mom or J. random programmer who hasn't got a doctorate in advanced
degree in math) expect a uniquely determined result which is IN the
initial set. I think we should offer that. If we offer something
else, that's fine. But don't do it on MAX. And don't be so stubborn
that you can't provide the MAX that 99.9% of your users are clearly
asking for.
Most "normal people" expect the distributive law to be true too, but with
inexact numbers, it won't necessarily be. In English we can certainly say
that + returns "the sum" of two numbers, but once inexact numbers are
involved any given Scheme implementation can only claim to compute a
representation of that sum.
(+ 1.0 1e20) ==> 1.0
Having added something non-zero to an inexact 1, should I be concerned that
the result is EQV? to the argument? My mom would probably complain that
the answer should be -different-, yet here Scheme might even return
something that is EQ?. Suppose I was planning on feeding this result to
MEMBER? or ASSOC? -- isn't this just as bad as what MAX does?
Inexact numbers simply do not behave like numbers. Abstractly MAX computes
the maximum of a set of numbers just as much as + computes the sum, but
unfortunately we can only represent numbers imperfectly in our computers
∂26-Jul-89 0408 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #169
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 26 Jul 89 04:08:41 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA24385; Wed, 26 Jul 89 06:42:22 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa17897;
26 Jul 89 0:07 EDT
Date: 26 JUL 89 00:07:12 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #169
To: Scheme@mc.lcs.mit.edu
Reply-To: Scheme@mc.lcs.mit.edu
Message-Id: <8907260007.aa17897@mintaka.lcs.mit.edu>
Scheme Digest #169 26 JUL 89 00:07:12 EDT
Today's Topics:
equal? Bug in PC Scheme
----------------------------------------------------------------------
Date: 25 Jul 89 19:10 GMT+0100
From: Guenther Goerz <goerz@rz.informatik.uni-hamburg.dbp.de>
Message-ID: <44:goerz@rz.informatik.uni-hamburg.dbp.de>
Subject: equal? Bug in PC Scheme
There seems to be a bug in PC Scheme's (ver. 3.03) EQUAL?: If you ask
whether the empty vector equals the empty vector, it says false.
(equal? #() #()) => ()
Vector is the only datatype where this happens.
---Guenther
------------------------------
End of Scheme Digest
********************
∂26-Jul-89 0617 ramsdell@linus.mitre.org INF/SUP/MIN/MAX
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 26 Jul 89 06:17:26 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA25417; Wed, 26 Jul 89 08:59:55 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA27863; Wed, 26 Jul 89 08:55:02 EDT
Posted-Date: Wed, 26 Jul 89 08:54:59 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA01126; Wed, 26 Jul 89 08:55:00 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8907261255.AA01126@huxley.mitre.org>
To: JMiller@crl.enet.dec.com
Cc: rrrs-authors@life.ai.mit.edu
Subject: INF/SUP/MIN/MAX
In-Reply-To: Your message of Fri, 21 Jul 89 09:30:45 -0400.
<8907211330.AA00412@peanut.DEC.COM>
Date: Wed, 26 Jul 89 08:54:59 EDT
I vote for excluding procedures named INF and SUP, and including
procedures named MIN and MAX having the semantics as documented in
R3.95RS. I encourage the editors to add a note describing the
"suprizing" behavior of MIN and MAX.
John
∂26-Jul-89 0745 wand@corwin.ccs.northeastern.edu INF/SUP/MIN/MAX
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 26 Jul 89 07:45:46 PDT
Received: from helios.northeastern.edu by life.ai.mit.edu (4.1/AI-4.10) id AA26157; Wed, 26 Jul 89 10:33:25 EDT
Received: from corwin.ccs.northeastern.edu by helios.northeastern.edu
id aa01420; 26 Jul 89 15:30 EST
Received: by corwin.CCS.Northeastern.EDU (5.51/SMI-3.2+CCS-main-2.6)
id AA00386; Wed, 26 Jul 89 10:00:19 ADT
Date: Wed, 26 Jul 89 10:00:19 ADT
From: Mitchell Wand <wand@corwin.ccs.northeastern.edu>
Message-Id: <8907261300.AA00386@corwin.CCS.Northeastern.EDU>
To: ramsdell@linus.mitre.org
Cc: JMiller@crl.enet.dec.com, rrrs-authors@life.ai.mit.edu
In-Reply-To: ramsdell@linus.mitre.org's message of Wed, 26 Jul 89 08:54:59 EDT <8907261255.AA01126@huxley.mitre.org>
Subject: INF/SUP/MIN/MAX
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Posted-Date: Wed, 26 Jul 89 08:54:59 EDT
From: ramsdell@linus.mitre.org
To: JMiller@crl.enet.dec.com
Cc: rrrs-authors@life.ai.mit.edu
Subject: INF/SUP/MIN/MAX
Date: Wed, 26 Jul 89 08:54:59 EDT
I vote for excluding procedures named INF and SUP, and including
procedures named MIN and MAX having the semantics as documented in
R3.95RS. I encourage the editors to add a note describing the
"suprizing" behavior of MIN and MAX.
John
This is my vote, also. As Alan Bawden said, "inexact numbers just don't
behave like numbers", so all we can do is make the language as consistent as
possible. I don't see that changing the names will help very much, except to
make the language harder to use.
--Mitch
∂26-Jul-89 1103 @mc.lcs.mit.edu,@life.ai.mit.edu:gls@think.com INF/SUP/MIN/MAX
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 26 Jul 89 11:01:41 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA28157; Wed, 26 Jul 89 13:41:27 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa24940;
26 Jul 89 13:14 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 26 Jul 89 13:07:23 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa24717;
26 Jul 89 13:00 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA27708; Wed, 26 Jul 89 13:00:19 EDT
Received: from Think.COM ([131.239.2.1]) by zurich.ai.mit.edu; Wed, 26 Jul 89 12:56:55 edt
Received: from fafnir.think.com by Think.COM; Wed, 26 Jul 89 13:00:30 EDT
Received: from verdi.think.com by fafnir.think.com; Wed, 26 Jul 89 12:58:19 EDT
Received: by verdi.think.com; Wed, 26 Jul 89 12:58:15 EDT
Date: Wed, 26 Jul 89 12:58:15 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8907261658.AA07734@verdi.think.com>
To: Alan@reagan.ai.mit.edu
Cc: KMP@stony-brook.scrc.symbolics.com, RRRS-Authors@zurich.ai.mit.edu
In-Reply-To: Alan Bawden's message of Wed, 26 Jul 89 01:15 EDT <19890726051514.2.ALAN@PIGPEN.AI.MIT.EDU>
Subject: INF/SUP/MIN/MAX
Date: Wed, 26 Jul 89 01:15 EDT
From: Alan Bawden <Alan@reagan.ai.mit.edu>
... I must say, it's more fun arguing with Steele.
Thank you. I guess.
Most "normal people" expect the distributive law to be true too, but with
inexact numbers, it won't necessarily be. In English we can certainly say
that + returns "the sum" of two numbers, but once inexact numbers are
involved any given Scheme implementation can only claim to compute a
representation of that sum.
(+ 1.0 1e20) ==> 1.0
Having added something non-zero to an inexact 1, should I be concerned that
the result is EQV? to the argument? My mom would probably complain that
the answer should be -different-, yet here Scheme might even return
something that is EQ?.
Hm. My mom might complain about this one too. Maybe you meant "1e-20"?
Or else you got ripped off if you paid more than $2 for that implementation.
Suppose I was planning on feeding this result to
MEMBER? or ASSOC? -- isn't this just as bad as what MAX does?
No, it isn't, Alan, and here's why. Your example takes what we might expect
to be two things and makes them one. This happens all the time in real life.
The morning star turns out to be the evening star also. Your mom turns out to
be the one who makes those yummy chocolate-chip cookies that are sold
nation-wide. Your car turns out to be eqv? to your cdr. You have two pennies
and put one on the railroad track, and the other one gets squished. [This
last example does not outrage intuition if pointers are used: "Last week I
heard that Weinreb had acquired a rare 1903 Quux-head penny. Yesterday at the
party Steele was showing off a penny just like it, and he put it on the
railroad track and it got squished. Today I asked Weinreb if I could see his
penny, and he sadly showed me that it had been squished." This story rendered
into Scheme is:
(penny? Weinreb) => #t
(set! Steele (+ Weinreb 1e-20))
(penny? Steele) => #t
(squish Steele)
(squished? Weinreb) => #t
] You thought + would give you a different number, but because of
machine limitations it gave you the same one back.
It is a much more egregious error to take what you thought you knew to be
one object and make it two. You thought there was only one Venus, but it
turns out that in August it takes a vacation and some asteroid fills in for
a month. You discover that your mom has a twin sister who baked all the
chocolate-chip cookies you used to love when you were a kid (and all these
years you just thought she was absent-minded when she was baking!). Your
car turns out not to be eqv? to your car. Weinreb and Steele jointly
invest in a rare Quux-head penny; then Weinreb tells his insurance company
that his penny got squished, while Steele sells his, in mint condition, to
a collector.
Discovering that two objects are really one is a lot of what computation is
all about: it means you have discovered an interesting cycle in a graph of
relationships. But discovering that one object is really two is a subversion
of naming and the entire notion of object identity. This is why people get
upset over MAX not returning one of its arguments. Suppose you took bids from
three carpenters and asked me to select the best one, and I replied that the
best of the three was some fourth carpenter you never heard of. Yes, his bid
and reputation are, as close as one can tell, at least as good as the best
actually submitted, but such shenanigans would be enough to get me thrown out
of public office. (That's what I get for accepting bids from inexact carpenters.)
--Guy
P.S. Isn't it nice to be arguing this issue on clear-cut technical grounds
instead of just flaming away at each other? :-)
∂26-Jul-89 1119 @mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu INF/SUP/MIN/MAX
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 26 Jul 89 11:19:16 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA28320; Wed, 26 Jul 89 13:52:08 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa25417;
26 Jul 89 13:38 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 26 Jul 89 13:38:15 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa25407;
26 Jul 89 13:36 EDT
Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA28048; Wed, 26 Jul 89 13:36:31 EDT
Received: from localhost by zurich.ai.mit.edu; Wed, 26 Jul 89 13:33:14 edt
Date: Wed, 26 Jul 89 13:33:14 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
Message-Id: <8907261733.AA22254@zurich.ai.mit.edu>
To: Alan@reagan.ai.mit.edu
Cc: RRRS-Authors@zurich.ai.mit.edu
In-Reply-To: Alan Bawden's message of Wed, 26 Jul 89 01:15 EDT <19890726051514.2.ALAN@PIGPEN.AI.MIT.EDU>
Subject: INF/SUP/MIN/MAX
Date: Wed, 26 Jul 89 01:15 EDT
From: Alan Bawden <Alan@reagan.ai.mit.edu>
Date: Tue, 25 Jul 89 19:06 EDT
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
...
In my opinion, the whole INF/SUP debate comes down to a haughty
disregard on the part of some designers for a clearly expressed need on
the part of users.
I don't see anybody else here defending this point of view, so it must be
me who is being "haughty". Below, I apparently become "anal" and
"stubborn". I must say, it's more fun arguing with Steele.
Just for the record, so far I agree with you Alan. I've been
following the discussion but haven't said anything because I felt you
have been making arguments at least as good as any I could.
∂26-Jul-89 1122 @mc.lcs.mit.edu,@life.ai.mit.edu:gls@think.com INF/SUP/MIN/MAX follow-up
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 26 Jul 89 11:21:43 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA28238; Wed, 26 Jul 89 13:45:03 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa24989;
26 Jul 89 13:15 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 26 Jul 89 13:13:48 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa24778;
26 Jul 89 13:07 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA27775; Wed, 26 Jul 89 13:07:28 EDT
Received: from Think.COM ([131.239.2.1]) by zurich.ai.mit.edu; Wed, 26 Jul 89 13:04:15 edt
Received: from fafnir.think.com by Think.COM; Wed, 26 Jul 89 13:07:52 EDT
Received: from verdi.think.com by fafnir.think.com; Wed, 26 Jul 89 13:05:37 EDT
Received: by verdi.think.com; Wed, 26 Jul 89 13:05:35 EDT
Date: Wed, 26 Jul 89 13:05:35 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8907261705.AA08756@verdi.think.com>
To: Alan@reagan.ai.mit.edu
Cc: KMP@stony-brook.scrc.symbolics.com, RRRS-Authors@zurich.ai.mit.edu
In-Reply-To: Alan Bawden's message of Wed, 26 Jul 89 01:15 EDT <19890726051514.2.ALAN@PIGPEN.AI.MIT.EDU>
Subject: INF/SUP/MIN/MAX follow-up
Warning: serious message follows. :-|
Actually, the remark that "inexact numbers just't don't behave like numbers"
prompts me to ask "are inexact numbers expected to behave like objects"?
Maybe inexact numbers should be totally excused from the requirements of object
identity. (They don't know just who they are, so why should anyone else?)
This also provides a loophole big enough to drive a pdl-number through.
--Guy
∂26-Jul-89 1215 @mc.lcs.mit.edu,@life.ai.mit.edu:KMP@stony-brook.scrc.symbolics.com INF/SUP/MIN/MAX
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 26 Jul 89 12:13:56 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA29060; Wed, 26 Jul 89 14:54:40 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa26105;
26 Jul 89 14:48 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 26 Jul 89 14:48:08 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa26031;
26 Jul 89 14:41 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA28880; Wed, 26 Jul 89 14:40:57 EDT
Received: from STONY-BROOK.SCRC.Symbolics.COM (stony-brook.scrc.symbolics.com) by zurich.ai.mit.edu; Wed, 26 Jul 89 14:37:43 edt
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 631902; 26 Jul 89 14:41:59 EDT
Date: Wed, 26 Jul 89 14:41 EDT
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Subject: INF/SUP/MIN/MAX
To: Alan@reagan.ai.mit.edu
Cc: KMP@stony-brook.scrc.symbolics.com, RRRS-Authors@zurich.ai.mit.edu
In-Reply-To: <19890726051514.2.ALAN@PIGPEN.AI.MIT.EDU>
Message-Id: <19890726184151.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Wed, 26 Jul 89 01:15 EDT
From: Alan Bawden <Alan@reagan.ai.mit.edu>
I've never heard users asking for the notion of exactness/inexactness at
all. Ask them what they want, and they will probably tell you that they
want IEEE floating point. As I have said before, I think it would be 100%
reasonable for Scheme to do what every other language does, and adopt some
reasonable set of rules for the behavior of floating point. Unfortunately,
Scheme decided to go in a different direction. Inexact numbers are not
just another name for floating point, so we have -already- decided to give
users something other than what they would ask for. What we are arguing
about here, are the -consequences- of that decision for the function MIN.
I was under the impression that the consistency of the language mattered,
not just what the users think they want before you have a chance to explain
the issues to them.
Well, it's funny because I agree with you on the language design
consistency issue, so I guess the fact I still feel bugged by this
issue exposes the fact that I really think that the decision of Scheme
(an otherwise serious language) to go with this baroque (albeit
mathematically elegant) theory of numbers is like asking the computer
community not to take it seriously. It would be one thing if it -also-
provided floats, so that people could get real work done while they
waited for the other stuff to get field tested, but my own cynical
viewpoint is that--for quite a while yet, anyway-- implementations are
likely to be either correct or efficient, but not both. At least with
floats the fact that games are being played is above board, and you
don't have to fail to conform in order to use standard hardware.
It reminds me of something I saw in the MGLA (Massachusetts General Law
Annotated) about stop light laws. It goes into elaborate detail about
how a city should compute how long a red light should be and it's
careful to point out that if you make the light too long, you encourage
disrespect for the law. I think the point about inconvenience breeding
disrespect is an important one: We have created a theory of numbers so
strange that it's likely that a noticeable fraction of would-be
implementors will implement all of the spec except for numbers. That's
a shame because it encourages the idea that it's ok to deviate from the
spec. I'd personally rather see something that people could implement
usefully, efficiently, straightforwardly and adhere so that there could
be lots of sparklingly conforming implementations. If there's one
thing we've learned from Common Lisp --for whatever you may think of
the particular `semantics' it has--it's that there's tremendous value
in just having agreed on something and made it widely available.
I would also go farther and say that these days I am starting to
believe that what is more important than language standards is datatype
standards. We always speak as if the different languages are just
different syntaxes for saying essentially the same thing. That is,
whether I choose to write FORTRAN
X=A*B
or Lisp
(SETQ X (* A B))
is really an issue of my preferred syntax. But if the primitive
operators themselves compute differing quantities, or if the data types
being passed around do not have a common significance to the different
languages, then the choice of language has an unreasonably elevated
importance because it brings with it an entire philosophy that the
other language much match up to, or must simulate. Someone needs to
start agreeing on a common set of interchange terminology for two
languages to talk to one another. I see most other languages involved
in trying to be able to talk to one another. But I see Scheme crawling
into a corner and refusing to acknowledge the metaphors that those
other languages have chosen. I am not sure this is a good thing.
I agree that advancement must always involve some degree of going
against the grain, but perhaps what I'm saying is that the world is not
exactly knocking at the door of the Scheme community asking where it
should go next. If Scheme wants to affect what is going on, its users
need to start to offer some success stories about what you can do with
its stylized view of numbers that you can't do with `ordinary' numbers,
and start to convince other communities that this is worth paying
attention to. For example, I think that Scheme has credibly done with
`continuations' -- not everyone thinks that first class continuations
are the right thing for every language (some don't even think they're
right for Scheme) but no one can deny that they are -seriously-
interesting, and have led to interesting successes/insights that might
not have been gotten via other means. If Scheme numbers are to persist
in their current form, I would like to be able to speak as confidently
about their demonstrated usefulness, and I don't now feel that I have
the ammunition to do so.
... I must say, it's more fun arguing with Steele.
Good of you to point this out. I'll have to make a point of keeping him
in my camp on arguments so he can guest host my disputes with you when
my overnight ratings start to dip and my sponsors are getting nervous
about me.
Seriously though, I apologize if I seemed a little on the accusing side.
But I am able to contribute precious little time to the Scheme community
these days--much less than I'd like to anyway. So it was more important
to me to make my opinions apparent than to spend a lot of time figuring
out how to present them in the most palatable light.
I certainly didn't mean that anyone should take what I had to say
personally, but I do stand by my overall sense that the Scheme community
spends is traditionally so far to the `right' (language design
politics-wise) that it risks alienating a fair fraction of the tiny
little part of the marketplace (i'm thinking usage-wise, not money-wise,
btw) that is likely to have otherwise appealed to.
T did this in its early days, too, by the way, and while there was clearly
some good effects of that, there have also been good effects due to just
catering to the expressed wants of the actual users.
∂26-Jul-89 1334 @mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu INF/SUP/MIN/MAX
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 26 Jul 89 13:34:01 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA00185; Wed, 26 Jul 89 16:13:37 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa26967;
26 Jul 89 15:58 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 26 Jul 89 15:58:30 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa26908;
26 Jul 89 15:53 EDT
Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA29807; Wed, 26 Jul 89 15:52:46 EDT
Received: from localhost by zurich.ai.mit.edu; Wed, 26 Jul 89 15:49:33 edt
Date: Wed, 26 Jul 89 15:49:33 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
Message-Id: <8907261949.AA22282@zurich.ai.mit.edu>
To: gls@think.com
Cc: Alan@reagan.ai.mit.edu, KMP@stony-brook.scrc.symbolics.com,
RRRS-Authors@zurich.ai.mit.edu
In-Reply-To: Guy Steele's message of Wed, 26 Jul 89 12:58:15 EDT <8907261658.AA07734@verdi.think.com>
Subject: INF/SUP/MIN/MAX
Date: Wed, 26 Jul 89 12:58:15 EDT
From: Guy Steele <gls@think.com>
Suppose I was planning on feeding this result to
MEMBER? or ASSOC? -- isn't this just as bad as what MAX does?
No, it isn't, Alan, and here's why. Your example takes what we might expect
to be two things and makes them one. This happens all the time in real life.
The morning star turns out to be the evening star also. Your mom turns out to
be the one who makes those yummy chocolate-chip cookies that are sold
nation-wide. Your car turns out to be eqv? to your cdr. You have two pennies
and put one on the railroad track, and the other one gets squished. [This
last example does not outrage intuition if pointers are used: "Last week I
heard that Weinreb had acquired a rare 1903 Quux-head penny. Yesterday at the
party Steele was showing off a penny just like it, and he put it on the
railroad track and it got squished. Today I asked Weinreb if I could see his
penny, and he sadly showed me that it had been squished." This story rendered
into Scheme is:
(penny? Weinreb) => #t
(set! Steele (+ Weinreb 1e-20))
(penny? Steele) => #t
(squish Steele)
(squished? Weinreb) => #t
] You thought + would give you a different number, but because of
machine limitations it gave you the same one back.
It is a much more egregious error to take what you thought you knew to be
one object and make it two. You thought there was only one Venus, but it
turns out that in August it takes a vacation and some asteroid fills in for
a month. You discover that your mom has a twin sister who baked all the
chocolate-chip cookies you used to love when you were a kid (and all these
years you just thought she was absent-minded when she was baking!). Your
car turns out not to be eqv? to your car. Weinreb and Steele jointly
invest in a rare Quux-head penny; then Weinreb tells his insurance company
that his penny got squished, while Steele sells his, in mint condition, to
a collector.
Discovering that two objects are really one is a lot of what computation is
all about: it means you have discovered an interesting cycle in a graph of
relationships. But discovering that one object is really two is a subversion
of naming and the entire notion of object identity. This is why people get
upset over MAX not returning one of its arguments. Suppose you took bids from
three carpenters and asked me to select the best one, and I replied that the
best of the three was some fourth carpenter you never heard of. Yes, his bid
and reputation are, as close as one can tell, at least as good as the best
actually submitted, but such shenanigans would be enough to get me thrown out
of public office. (That's what I get for accepting bids from inexact carpenters.)
--Guy
P.S. Isn't it nice to be arguing this issue on clear-cut technical grounds
instead of just flaming away at each other? :-)
I don't buy these arguments: many of them have to do with side
effects, and since when are there any side effects on numbers? So
they don't apply.
The rest, such as whether or not your car is eqv? to your car, don't
seem to contribute much to the discussion, except their obvious
entertainment value. Perhaps I'm making a mistake in taking any part
of your message seriously.
Maybe the problem isn't the action of max or min, but eqv? If we
considered equality as defined by = this question wouldn't come up.
Maybe eqv? is making too fine a distinction.
∂26-Jul-89 1405 @mc.lcs.mit.edu,@life.ai.mit.edu:gls@think.com INF/SUP/MIN/MAX
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 26 Jul 89 14:04:50 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA00594; Wed, 26 Jul 89 16:46:21 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa27244;
26 Jul 89 16:31 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 26 Jul 89 16:31:31 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa27180;
26 Jul 89 16:26 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA00258; Wed, 26 Jul 89 16:26:14 EDT
Received: from Think.COM ([131.239.2.1]) by zurich.ai.mit.edu; Wed, 26 Jul 89 16:23:01 edt
Received: from fafnir.think.com by Think.COM; Wed, 26 Jul 89 16:26:42 EDT
Received: from verdi.think.com by fafnir.think.com; Wed, 26 Jul 89 16:24:27 EDT
Received: by verdi.think.com; Wed, 26 Jul 89 16:24:25 EDT
Date: Wed, 26 Jul 89 16:24:25 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8907262024.AA06827@verdi.think.com>
To: cph@zurich.ai.mit.edu
Cc: gls@think.com, Alan@reagan.ai.mit.edu, KMP@stony-brook.scrc.symbolics.com,
RRRS-Authors@zurich.ai.mit.edu
In-Reply-To: Chris Hanson's message of Wed, 26 Jul 89 15:49:33 edt <8907261949.AA22282@zurich.ai.mit.edu>
Subject: INF/SUP/MIN/MAX
Date: Wed, 26 Jul 89 15:49:33 edt
From: cph@zurich.ai.mit.edu (Chris Hanson)
Date: Wed, 26 Jul 89 12:58:15 EDT
From: Guy Steele <gls@think.com>
Suppose I was planning on feeding this result to
MEMBER? or ASSOC? -- isn't this just as bad as what MAX does?
No, it isn't, Alan, and here's why. Your example takes what we might expect
to be two things and makes them one. This happens all the time in real life.
The morning star turns out to be the evening star also. Your mom turns out to
be the one who makes those yummy chocolate-chip cookies that are sold
nation-wide. Your car turns out to be eqv? to your cdr. You have two pennies
and put one on the railroad track, and the other one gets squished. [This
last example does not outrage intuition if pointers are used: "Last week I
heard that Weinreb had acquired a rare 1903 Quux-head penny. Yesterday at the
party Steele was showing off a penny just like it, and he put it on the
railroad track and it got squished. Today I asked Weinreb if I could see his
penny, and he sadly showed me that it had been squished." This story rendered
into Scheme is:
(penny? Weinreb) => #t
(set! Steele (+ Weinreb 1e-20))
(penny? Steele) => #t
(squish Steele)
(squished? Weinreb) => #t
] You thought + would give you a different number, but because of
machine limitations it gave you the same one back.
It is a much more egregious error to take what you thought you knew to be
one object and make it two. You thought there was only one Venus, but it
turns out that in August it takes a vacation and some asteroid fills in for
a month. You discover that your mom has a twin sister who baked all the
chocolate-chip cookies you used to love when you were a kid (and all these
years you just thought she was absent-minded when she was baking!). Your
car turns out not to be eqv? to your car. Weinreb and Steele jointly
invest in a rare Quux-head penny; then Weinreb tells his insurance company
that his penny got squished, while Steele sells his, in mint condition, to
a collector.
Discovering that two objects are really one is a lot of what computation is
all about: it means you have discovered an interesting cycle in a graph of
relationships. But discovering that one object is really two is a subversion
of naming and the entire notion of object identity. This is why people get
upset over MAX not returning one of its arguments. Suppose you took bids from
three carpenters and asked me to select the best one, and I replied that the
best of the three was some fourth carpenter you never heard of. Yes, his bid
and reputation are, as close as one can tell, at least as good as the best
actually submitted, but such shenanigans would be enough to get me thrown out
of public office. (That's what I get for accepting bids from inexact carpenters.)
--Guy
P.S. Isn't it nice to be arguing this issue on clear-cut technical grounds
instead of just flaming away at each other? :-)
I don't buy these arguments: many of them have to do with side
effects, and since when are there any side effects on numbers? So
they don't apply.
Granted. "Plus ca change, plus c'est la meme chose", as Sussman and I
quoted in "The Art of the Interpreter". The more things change, the more
they remain the same; that is, the notion of object identity may be linked
to the notion of side effect. And yet, if numbers are not subject to
side effects, in what sense can we say that 1 = 1, or that 1 /= 2 ?
I think that when we say 1 = 1, we are temporarily entertaining the
possibility that the two instances of "1" represent *different* things,
precisely so that we may then make the assertion that they are the same
after all. If one of the 1's were not 1 after all, then things would be
different, including the truth of the equality. This subjunctive
hypothesis amounts to a side effect, for we are considering, hypothetically
and however evanescently, a world altered from our own (whether by SETQ
or by adding an entry to the head of an a-list).
The rest, such as whether or not your car is eqv? to your car, don't
seem to contribute much to the discussion, except their obvious
entertainment value. Perhaps I'm making a mistake in taking any part
of your message seriously.
On the contrary, I am trying (admittedly by entertaining means) to get at
the root of our intuitions about object identity, as I and many of us have
been doing for years now. The entire point is that it is hardly surprising
to discover that (eqv? (car x) (cdr x)) is true; but it is horrifying to
discover that (eqv? (car x) (car x)) is false, and we go scurrying for
possible explanations (a parallel process maybe did a side effect between
the two calls to car ?). The two cases are quite different.
Maybe the problem isn't the action of max or min, but eqv? If we
considered equality as defined by = this question wouldn't come up.
Maybe eqv? is making too fine a distinction.
Indeed, and this is essentially the subject of the message I sent
after this one (the one you replied to): maybe inexact numbers
should not possess object identity. Please take this seriously.
(Maybe it's the wrong idea, but it's not a frivolous idea, I think.)
--Guy
∂26-Jul-89 1437 @mc.lcs.mit.edu,@life.ai.mit.edu:gjs@hpesogg.hp.com INF/SUP/MIN/MAX
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 26 Jul 89 14:37:39 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA00957; Wed, 26 Jul 89 17:25:05 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa27603;
26 Jul 89 17:09 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 26 Jul 89 17:09:11 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa27573;
26 Jul 89 17:03 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA00771; Wed, 26 Jul 89 17:03:19 EDT
Received: from sde.hp.com (sde.hp.com) by zurich.ai.mit.edu; Wed, 26 Jul 89 17:00:05 edt
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.6b/SES42.42) id AA11348; Wed, 26 Jul 89 14:02:53 pdt
Message-Id: <8907262102.AA11348@sde.hp.com>
Received: by hpesogg; Wed, 26 Jul 89 14:01:54 pdt
Date: Wed, 26 Jul 89 14:01:54 pdt
From: Gerald Jay Sussman <gjs@hpesogg.hp.com>
To: Alan@reagan.ai.mit.edu
Cc: RRRS-Authors@zurich.ai.mit.edu
Subject: INF/SUP/MIN/MAX
I don't see anybody else here defending this point of view, so it must be
me who is being "haughty". Below, I apparently become "anal" and
"stubborn". I must say, it's more fun arguing with Steele.
Keep up the good work, I keep my mouth shut when I watch a master in
action. And don't let the nasty things some people say get to you.
Steele is indeed fun, we need more of his time!
∂26-Jul-89 1952 @mc.lcs.mit.edu,@life.ai.mit.edu:kempf@sun.com Please Remove
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 26 Jul 89 19:52:28 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA03711; Wed, 26 Jul 89 22:37:02 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa00828;
26 Jul 89 22:25 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 26 Jul 89 22:25:32 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa00818;
26 Jul 89 22:22 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA03668; Wed, 26 Jul 89 22:22:45 EDT
Received: from Sun.COM ([192.9.9.1]) by zurich.ai.mit.edu; Wed, 26 Jul 89 22:19:32 edt
Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1)
id AA25442; Wed, 26 Jul 89 19:22:26 PDT
Received: from suntana.sun.com by snail.Sun.COM (4.1/SMI-4.1)
id AA22947; Wed, 26 Jul 89 12:46:45 PDT
Received: from localhost by suntana.sun.com (4.0/SMI-4.0)
id AA01346; Wed, 26 Jul 89 12:47:25 PDT
Message-Id: <8907261947.AA01346@suntana.sun.com>
To: rrrs-authors@zurich.ai.mit.edu
Subject: Please Remove
Date: Wed, 26 Jul 89 12:47:23 PDT
From: kempf@sun.com
I tried rrrs-authors-request, but that didn't work, so, risking flamage,
here is a request to remove me from this list. Thanx.
jak
∂27-Jul-89 0855 @mc.lcs.mit.edu,@life.ai.mit.edu:gls@think.com INF/SUP/MIN/MAX
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 27 Jul 89 08:54:51 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA09751; Thu, 27 Jul 89 11:31:55 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa09635;
27 Jul 89 11:26 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 27 Jul 89 11:26:41 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa09599;
27 Jul 89 11:20 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA09544; Thu, 27 Jul 89 11:20:02 EDT
Received: from Think.COM ([131.239.2.1]) by zurich.ai.mit.edu; Thu, 27 Jul 89 11:16:45 edt
Received: from fafnir.think.com by Think.COM; Thu, 27 Jul 89 11:19:39 EDT
Received: from verdi.think.com by fafnir.think.com; Thu, 27 Jul 89 11:17:23 EDT
Received: by verdi.think.com; Thu, 27 Jul 89 11:17:20 EDT
Date: Thu, 27 Jul 89 11:17:20 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8907271517.AA11786@verdi.think.com>
To: wand@corwin.ccs.northeastern.edu
Cc: gls@think.com, cph@zurich.ai.mit.edu, gls@think.com,
Alan@reagan.ai.mit.edu, KMP@stony-brook.scrc.symbolics.com,
RRRS-Authors@zurich.ai.mit.edu
In-Reply-To: Mitchell Wand's message of Thu, 27 Jul 89 09:30:53 ADT <8907271230.AA08188@corwin.CCS.Northeastern.EDU>
Subject: INF/SUP/MIN/MAX
Date: Thu, 27 Jul 89 09:30:53 ADT
From: Mitchell Wand <wand@corwin.ccs.northeastern.edu>
Date: Wed, 26 Jul 89 16:24:25 EDT
From: Guy Steele <gls@think.com>
Date: Wed, 26 Jul 89 15:49:33 edt
From: cph@zurich.ai.mit.edu (Chris Hanson)
...
I don't buy these arguments: many of them have to do with side
effects, and since when are there any side effects on numbers? So
they don't apply.
Granted. "Plus ca change, plus c'est la meme chose", as Sussman and I
quoted in "The Art of the Interpreter". The more things change, the more
they remain the same; that is, the notion of object identity may be linked
to the notion of side effect. And yet, if numbers are not subject to
side effects, in what sense can we say that 1 = 1, or that 1 /= 2 ?
I think that when we say 1 = 1, we are temporarily entertaining the
possibility that the two instances of "1" represent *different* things,
precisely so that we may then make the assertion that they are the same
after all. If one of the 1's were not 1 after all, then things would be
different, including the truth of the equality. This subjunctive
hypothesis amounts to a side effect, for we are considering, hypothetically
and however evanescently, a world altered from our own (whether by SETQ
or by adding an entry to the head of an a-list).
I'm not convinced by this argument. While it is surely true that object
identity is linked to the notion of side-effect, it does not follow that the
truth or falsity of the proposition "1=1" has some subjunctive hypothesis that
amounts to a side effect. If there were a subjunctive hypothesis in "1=1", it
would range over the class of propositions, ie those questions of the form
`M = N', as M and N range over some class of expressions. The proposition
asks whether M and N denote the same thing. So "1 = 1" is true, but "1 = 2"
is false.
Let me recapitulate the form of my entire argument. I claimed:
A property that many programmers expect of MAX is that
if (MAX a b c ...) => x then x=a or x=b or x=c or ...
where I use infix "=" to mean object identity. I complained
that the MAX in R3.95 fails to have this property.
Alan then compared this situation to that of +, remarking that
+ also fails, by returning something the same as an argument
when you expected it to be different.
I then countered that these were two different types of failure:
MAX fails to preserve object identity (given that one's model
of its behavior or implementation is that it ought to), whereas
+ fails to preserve object distinctness (given that a model
of the algebraic properties of + says they ought to be distinct.
Chris then objected that many of my informal examples revolved around the
notion of side effect, but because numbers as such are not subject to side
effects in Scheme those arguments were therefore irrelevant.
My reply was an attempt to restate my point about object identity
more clearly, but it is hard to discuss object identity without
dragging in side effects to some extent.
The failure of + to preserve object distinctness--that is, the failure
to obey the law
if x /= 0 then x+y /= x
may be regarded as a bad definition or implementation of +.
On the other hand, a failure to preserve object identity in MAX,
while it may also be regarded as a bad definition or implementation
of MAX, also looks suspiciously like a breakdown of the naming or
equality mechanisms in the language, and is therefore much more disturbing.
I believe that "1 = 1" does entail a subjunctive hypothesis at some
stage if its interpretation process, because I regard the mark "1"
on the paper as a numeral and not a number; it's just another name,
one I have agreed not to alter capriciously most of the time.
(But you know what I mean when I say "He has fourteen cats--for some
value of fourteen.") Until I have interpreted that mark and evaluated
it to the Platonic number one, there is the possibility that the
equality fails to hold. Or I could regard the equality algebraically
instead of numerically, noting that the two sides are symbolically
identical; but then in deducing the truth of the equality I assume
that no side effect would take place during the hypothetical eventual
evaluation of the expressions. It is not so much, I guess, that
the hypothesis *is* a side effect, as that it temporarily entertains
the possibility that one might occur.
--Guy
∂27-Jul-89 1106 @mc.lcs.mit.edu,@life.ai.mit.edu:gls@think.com INF/SUP/MIN/MAX and correct use of time
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 27 Jul 89 11:05:58 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA11699; Thu, 27 Jul 89 13:50:57 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa09793;
27 Jul 89 11:33 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 27 Jul 89 11:33:15 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa09622;
27 Jul 89 11:24 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA09615; Thu, 27 Jul 89 11:24:50 EDT
Received: from Think.COM ([131.239.2.1]) by zurich.ai.mit.edu; Thu, 27 Jul 89 10:33:47 edt
Received: from fafnir.think.com by Think.COM; Thu, 27 Jul 89 10:35:49 EDT
Received: from verdi.think.com by fafnir.think.com; Thu, 27 Jul 89 10:33:30 EDT
Received: by verdi.think.com; Thu, 27 Jul 89 10:33:25 EDT
Date: Thu, 27 Jul 89 10:33:25 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8907271433.AA07821@verdi.think.com>
To: gjs@hpesogg.hp.com
Cc: Alan@reagan.ai.mit.edu, RRRS-Authors@zurich.ai.mit.edu
In-Reply-To: Gerald Jay Sussman's message of Wed, 26 Jul 89 14:01:54 pdt <8907262102.AA11348@sde.hp.com>
Subject: INF/SUP/MIN/MAX and correct use of time
Date: Wed, 26 Jul 89 14:01:54 pdt
From: Gerald Jay Sussman <gjs@hpesogg.hp.com>
I don't see anybody else here defending this point of view, so it must be
me who is being "haughty". Below, I apparently become "anal" and
"stubborn". I must say, it's more fun arguing with Steele.
Keep up the good work, I keep my mouth shut when I watch a master in
action. And don't let the nasty things some people say get to you.
Steele is indeed fun, we need more of his time!
Lest anyone think Alan and I have become bitter adversaries,
or that we are not spending our time appropriately, let me report
(forgive me, Alan) that we coincidentally ended up at the same
movie showing yesterday afternoon and when we met we grinned
at each other and shook hands. We know how to spend our time.
Incidentally, "The Brave Little Toaster" is pretty fair animation, great
storytelling for the age level it is nominally pitched at, good
characterization (given that the heroes are household appliances), and has
some fine parody sequences for us so-called grown-ups. (Maybe Alan will
have some differing opinion, and we can discuss *that* for a while. :-)
∂27-Jul-89 1116 @mc.lcs.mit.edu,@life.ai.mit.edu:wand@corwin.ccs.northeastern.edu INF/SUP/MIN/MAX
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 27 Jul 89 11:16:38 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA11722; Thu, 27 Jul 89 13:52:26 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa09801;
27 Jul 89 11:34 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 27 Jul 89 11:33:41 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa09627;
27 Jul 89 11:26 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA09628; Thu, 27 Jul 89 11:25:28 EDT
Received: from helios.northeastern.edu (helios.northeastern.edu) by zurich.ai.mit.edu; Thu, 27 Jul 89 10:02:21 edt
Received: from corwin.ccs.northeastern.edu by helios.northeastern.edu
id aa17480; 27 Jul 89 15:00 EST
Received: by corwin.CCS.Northeastern.EDU (5.51/SMI-3.2+CCS-main-2.6)
id AA08188; Thu, 27 Jul 89 09:30:53 ADT
Date: Thu, 27 Jul 89 09:30:53 ADT
From: Mitchell Wand <wand@corwin.ccs.northeastern.edu>
Message-Id: <8907271230.AA08188@corwin.CCS.Northeastern.EDU>
To: gls@think.com
Cc: cph@zurich.ai.mit.edu, gls@think.com, Alan@reagan.ai.mit.edu,
KMP@stony-brook.scrc.symbolics.com, RRRS-Authors@zurich.ai.mit.edu
In-Reply-To: Guy Steele's message of Wed, 26 Jul 89 16:24:25 EDT <8907262024.AA06827@verdi.think.com>
Subject: INF/SUP/MIN/MAX
[Just to make sure that everyone's archive's continue to grow quadratically, I
will follow the usual protocol of inserting an indented copy of the
correspondence up to this point.]
Date: Wed, 26 Jul 89 16:24:25 EDT
From: Guy Steele <gls@think.com>
To: cph@zurich.ai.mit.edu
Cc: gls@think.com, Alan@reagan.ai.mit.edu,
KMP@stony-brook.scrc.symbolics.com, RRRS-Authors@zurich.ai.mit.edu
Subject: INF/SUP/MIN/MAX
Date: Wed, 26 Jul 89 15:49:33 edt
From: cph@zurich.ai.mit.edu (Chris Hanson)
Date: Wed, 26 Jul 89 12:58:15 EDT
From: Guy Steele <gls@think.com>
Suppose I was planning on feeding this result to
MEMBER? or ASSOC? -- isn't this just as bad as what MAX does?
No, it isn't, Alan, and here's why. Your example takes what we might expect
to be two things and makes them one. This happens all the time in real life.
The morning star turns out to be the evening star also. Your mom turns out to
be the one who makes those yummy chocolate-chip cookies that are sold
nation-wide. Your car turns out to be eqv? to your cdr. You have two pennies
and put one on the railroad track, and the other one gets squished. [This
last example does not outrage intuition if pointers are used: "Last week I
heard that Weinreb had acquired a rare 1903 Quux-head penny. Yesterday at the
party Steele was showing off a penny just like it, and he put it on the
railroad track and it got squished. Today I asked Weinreb if I could see his
penny, and he sadly showed me that it had been squished." This story rendered
into Scheme is:
(penny? Weinreb) => #t
(set! Steele (+ Weinreb 1e-20))
(penny? Steele) => #t
(squish Steele)
(squished? Weinreb) => #t
] You thought + would give you a different number, but because of
machine limitations it gave you the same one back.
It is a much more egregious error to take what you thought you knew to be
one object and make it two. You thought there was only one Venus, but it
turns out that in August it takes a vacation and some asteroid fills in for
a month. You discover that your mom has a twin sister who baked all the
chocolate-chip cookies you used to love when you were a kid (and all these
years you just thought she was absent-minded when she was baking!). Your
car turns out not to be eqv? to your car. Weinreb and Steele jointly
invest in a rare Quux-head penny; then Weinreb tells his insurance company
that his penny got squished, while Steele sells his, in mint condition, to
a collector.
Discovering that two objects are really one is a lot of what computation is
all about: it means you have discovered an interesting cycle in a graph of
relationships. But discovering that one object is really two is a subversion
of naming and the entire notion of object identity. This is why people get
upset over MAX not returning one of its arguments. Suppose you took bids from
three carpenters and asked me to select the best one, and I replied that the
best of the three was some fourth carpenter you never heard of. Yes, his bid
and reputation are, as close as one can tell, at least as good as the best
actually submitted, but such shenanigans would be enough to get me thrown out
of public office. (That's what I get for accepting bids from inexact carpenters.)
--Guy
P.S. Isn't it nice to be arguing this issue on clear-cut technical grounds
instead of just flaming away at each other? :-)
I don't buy these arguments: many of them have to do with side
effects, and since when are there any side effects on numbers? So
they don't apply.
Granted. "Plus ca change, plus c'est la meme chose", as Sussman and I
quoted in "The Art of the Interpreter". The more things change, the more
they remain the same; that is, the notion of object identity may be linked
to the notion of side effect. And yet, if numbers are not subject to
side effects, in what sense can we say that 1 = 1, or that 1 /= 2 ?
I think that when we say 1 = 1, we are temporarily entertaining the
possibility that the two instances of "1" represent *different* things,
precisely so that we may then make the assertion that they are the same
after all. If one of the 1's were not 1 after all, then things would be
different, including the truth of the equality. This subjunctive
hypothesis amounts to a side effect, for we are considering, hypothetically
and however evanescently, a world altered from our own (whether by SETQ
or by adding an entry to the head of an a-list).
I'm not convinced by this argument. While it is surely true that object
identity is linked to the notion of side-effect, it does not follow that the
truth or falsity of the proposition "1=1" has some subjunctive hypothesis that
amounts to a side effect. If there were a subjunctive hypothesis in "1=1", it
would range over the class of propositions, ie those questions of the form
`M = N', as M and N range over some class of expressions. The proposition
asks whether M and N denote the same thing. So "1 = 1" is true, but "1 = 2"
is false. If we embed these in a programming language, then we can get
confused in two ways:
1. The value denoted by the expression M may be implementation-dependent.
Therefore the truth or falsity of "M = N" may be implementation-dependent.
2. The computation of M and N may cause side-effects which change the objects
that M and N compute. Thus (eqv? (car x) (car x)) may fail because there is
some parallel process interfering with the calculation.
It seems to me that (1) is the major source of problems here, because we have
been very careful to NOT completely specify the semantics of numbers (exact OR
inexact). Unless we want to go the whole way and talk about "inexact
booleans" (which I do not recommend), at some point we have to make a cut and
admit implementation-dependence rather than inexactness. [My guess is that
we've done a pretty good job of choosing where to make this cut, judging by
the arcana in the discussion so far]. We probably shouldn't get distracted by
(2), which seems largely independent.
The rest, such as whether or not your car is eqv? to your car, don't
seem to contribute much to the discussion, except their obvious
entertainment value. Perhaps I'm making a mistake in taking any part
of your message seriously.
On the contrary, I am trying (admittedly by entertaining means) to get at
the root of our intuitions about object identity, as I and many of us have
been doing for years now. The entire point is that it is hardly surprising
to discover that (eqv? (car x) (cdr x)) is true; but it is horrifying to
discover that (eqv? (car x) (car x)) is false, and we go scurrying for
possible explanations (a parallel process maybe did a side effect between
the two calls to car ?). The two cases are quite different.
Maybe the problem isn't the action of max or min, but eqv? If we
considered equality as defined by = this question wouldn't come up.
Maybe eqv? is making too fine a distinction.
Indeed, and this is essentially the subject of the message I sent
after this one (the one you replied to): maybe inexact numbers
should not possess object identity. Please take this seriously.
(Maybe it's the wrong idea, but it's not a frivolous idea, I think.)
--Guy
--Mitch
∂27-Jul-89 1122 @mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@relay.cs.net,@tektronix.tek.com:kend@mrloog.la.tek.com Re: Regularization of apply (long)
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 27 Jul 89 11:22:19 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA11909; Thu, 27 Jul 89 14:06:16 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa10786;
27 Jul 89 12:49 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 27 Jul 89 12:49:06 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa10746;
27 Jul 89 12:44 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA10663; Thu, 27 Jul 89 12:44:05 EDT
Received: from RELAY.CS.NET (relay.cs.net) by zurich.ai.mit.edu; Thu, 27 Jul 89 12:40:49 edt
Received: from tektronix.tek.com by RELAY.CS.NET id aa03574; 27 Jul 89 12:40 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
id AA05947; Thu, 27 Jul 89 09:41:35 PDT
Received: by dadla.LA.TEK.COM (5.51/6.24)
id AA06439; Thu, 27 Jul 89 09:22:54 PDT
Received: by mrloog.la.tek.com (1.2/7.1)
id AA08823; Thu, 27 Jul 89 09:27:42 pdt
Message-Id: <8907271627.AA08823@mrloog.la.tek.com>
To: jinx%hpesogg@sde.hp.com
Cc: rrrs-authors@zurich.ai.mit.edu, Scheme-Standard@wheaties.ai.mit.edu,
gls@think.com
Subject: Re: Regularization of apply (long)
Date: 27 Jul 89 09:27:35 PDT (Thu)
From: kend%mrloog.la.tek.com@relay.cs.net
>[Ken Dickey]
> I would prefer that APPLY be applicable only to multiple values. For
> that matter, I favor multiple value rest arguments--dropping rest *lists*
> altogether.
>[Jinx]
>What do you mean by multiple values?
>Do you mean something like LAMBDA*'s & pseudo-objects?
>If you mean something along the more traditional lines, you have just
>pushed the problem one level deeper, since your multiple value
>receivers are also expressed in lambda notation and therefore you need
>to have dotted lists.
Yes, I will say it. I like LAMBDA* [with some restrictions: single-value
assignments only, single rest argument, I prefer VALUES to #\& for multiple
value returns]. I use T's RETURN/RECEIVE and find multiple values quite
handy. LAMBDA* provides a convenient way to bind/spread multiple values.
There it is, out of the closet.
I happen to think that LAMBDA* can be compiled to add significant
performance (over rest lists), particularly in the presence of early
binding. I happen to be working in an environment where this matters
(semi-realtime embedded systems). Having the user do a case dispatch on
the number of arguments (particularly using rest lists) usually looses in
the speed department. I also think that errors are fewer when the
compiler can check them--and possibly optimize away the checks.
Your coroutines are pretty neat, but don't help me out much for
variable-arity proceedures.
(define PPRINT
(lambda*
[(<value> <port> <line-length>)
(%pprint <value> <port> <line-length>)]
[(<value> <port>)
(%pprint <value> <port> default-line-length)]
[(<value>)
(%pprint <value> (standard-output) default-line-length)]
) )
I know that you can construct code to handle such cases, but question
whether this can be compiled as efficently (given comparitive
implementation effort). Personally, I would rather have the
opportunities for optimization using multiple values and lambda* because
I think that we could do some really winning code generation.
-Ken Dickey kend@mrloog.LA.TEK.COM
∂27-Jul-89 1209 @mc.lcs.mit.edu,@life.ai.mit.edu:shaff@sesame.stanford.edu Multiple Values for R5RS (VERY LONG)
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 27 Jul 89 12:09:40 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA12542; Thu, 27 Jul 89 14:54:42 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa12121;
27 Jul 89 14:37 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 27 Jul 89 14:33:38 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa11974;
27 Jul 89 14:28 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA12213; Thu, 27 Jul 89 14:27:08 EDT
Received: from sesame.Stanford.EDU (sesame.stanford.edu) by zurich.ai.mit.edu; Thu, 27 Jul 89 14:23:39 edt
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA08835; Thu, 27 Jul 89 11:26:00 PDT
Date: Thu, 27 Jul 89 11:26:00 PDT
From: Mike Shaff <shaff@sesame.stanford.edu>
Message-Id: <8907271826.AA08835@sesame.Stanford.EDU>
To: RRRS-Authors@zurich.ai.mit.edu
Subject: Multiple Values for R5RS (VERY LONG)
The following proposal is for R5RS ****NOT**** R4RS.
It is our impression that the discussions at Snowbird on multiple values
broke down mostly due to misunderstandings. At this time, we would like to
make a proposal which we feel addresses all of the concerns expressed during
those and subsequent discussions. We would appreciate responses to this
proposal, both pro and con, so as to ensure continued discussion of this
issue, and its eventual (we hope) resolution.
This proposal contains the following components:
1. A description of the introduced procedures.
2. A discussion of a number of the design decisions.
3. A presentation of several 'higher' level constructs which can be
built using the introduced primitives.
Our proposal calls for the introduction of three new procedures, only one of
which does not have a naive implementation in R4RS. The functions and their
semantics are as follows (we suggest these names only to protect the
innocent):
(values obj ...) essential procedure
Returns 0 or more values to an accepting form.
(values) => returns zero (no) values
(values 1) => returns a single value, 1
(values 1 'a) => returns two values, 1 and the symbol a
(apply-values receiver generator) essential procedure
Applies the procedure 'receiver' to the values generated by thawing the
thunk, 'generator'. The arity of 'receiver' must be compatible with the
return-arity of 'generator' (i.e., the number of values returned by
'generator'). In the absence of a rest argument, the arity of 'receiver'
must be identical to the return-arity of 'generator'. The formals of
'receiver' will be bound to fresh locations and the values returned by
'generator' will be stored in the respective locations. When a rest
argument is present, the return-arity of 'generator' must be greater than or
equal to the number of required arguments to 'receiver'. The required
actuals will be handled as above; the rest argument will be bound to a fresh
location in which a newly created list, composed of the remaining actuals
returned by 'generator', will be stored. It is an error for the arity of
'receiver' and the return-arity of 'generator' to be incompatible. [This
will be discussed later in the proposal.]
(apply-values cons
(lambda ()
(values 1 2))) => (1 . 2)
(arity applicable) essential procedure
The argument to arity must be an applicable object (i.e., objects for which
procedure? returns #t). Arity returns three values: the minimum number of
actuals accepted by 'applicable', the maximum number of actuals accepted by
'applicable' (excluding, if present, a rest argument, and including optional
arguments, for those implementations that support optionals), and a boolean
representing the presence of a rest argument.
(arity car) => 1, 1, #f
(arity +) => 1, 1, #t
In an implementation that supports optional arguments (which we will denote
using &optional)...
(arity (lambda (x &optional y)
<body>)) => 1, 2, #f
(arity (lambda (x &optional y . rest)
<body>)) => 1, 2, #t
(car (call/cc
(lambda (k)
(arity k) ; arity would return 1, 1, #f
<body>)))
(apply-values cons
(lambda ()
(call/cc
(lambda (k)
(arity k) ; arity would return 2, 2, #f
<body>))))
(apply-values (lambda (. args)
<body>)
(lambda ()
(call/cc
(lambda (k)
(arity k) ; arity would return 0, 0, #t
<body>))))
(begin
<expression>
...
(call/cc
(lambda (k)
(arity k) ; arity would return 0, 0, #t
<body>))
...
<expression>)
If a continuation is captured in a tail-recursive position, the
continuation's arity is determined by the accepting stack frame.
(cons <expression>
(begin
<expression>
...
(call/cc
(lambda (k)
(arity k) ; arity would return 1, 1, #f
<body>))))
(apply-values +
(lambda ()
<expression>
...
(call/cc
(lambda (k)
(arity k) ; arity would return 0, 0, #t
<body>))))
A point of contention at Snowbird was the issue of incompatibility of arity
between generators and receivers. In our proposal returning to few values
is an error to maintain symmetry with procedure application. While there
seemed to be virtually universal agreement on the former point, the
appropriate manner of handling the return of more values than expected was
not agreed upon. Based on the following three considerations, we propose
that returning excessive values be considered an error:
1. Currently the application of a procedure to excessive arguments is
an error in RNRS; similarly, multiple value application of a
procedure to too many actuals should also be an error.
2. It is sometimes desirable to create upwardly compatible versions of
procedures by increasing their return-arity. This can be
accomplished through the use of 'call/cc' and 'arity'. For
example, the standard definition of 'quotient' could be extended to
return both the quotient and remainder, as follows:
(define quotient
(let ((original-quotient quotient))
(lambda (n1 n2)
(call/cc ;Capture the implicit continuation
(lambda (k)
(if (apply-values ;If k accepts more than one actual
(lambda (min max rest?)
(or rest?
(>= max 2)))
(lambda ()
(arity k)))
(values (original-quotient n1 n2)
(remainder n1 n2))
(original-quotient n1 n2)))))))
3. Some individuals at Snowbird desired CLtL semantics for the return
of multiple values to a form which expecting a single value (i.e.,
stripping). This functionality can be achieved using a
'first-value' procedure which can be written in standard RNRS.
(define first-value
(lambda (thunk)
(apply-values (lambda (return-me . rest)
return-me)
thunk)))
Further, a generalized values referencing procedure can be defined
as shown below:
(define values-ref
(lambda (thunk n)
(apply-values (lambda (. args)
(list-ref args n))
thunk)))
One of the advantages of this approach is that some programming
errors could be recognized at compile time; otherwise, these errors
would not be detectable until runtime.
NOTES:
1. In our proposal multiple return values are not a first class data type.
2. This proposal does NOT specify the return-arity of the current RNRS
procedures; but, this must be done as part of any eventually agreed upon
semantics for multiple values.
3. We would like (values <arg>) and <arg> to be operationally equivalent.
However in deference to implementors who want to minimize the number of
modifications needed to support multiple values, we have required only one
modification, the addition of the primitive arity. To get the semantics we
desire, it would appear that modification to an implementation's procedure
application mechanism would be required. If implementors are agreeable,
we advise that the above semantics be added to our working proposal.
Procedure application could then be viewed as syntactic sugar for a
multiple values application as shown below:
(f x y ...) = (apply-values f (lambda () (values x y ...)))
alpha
EXTRA FOR EXPERTS:
(define make-values->
(lambda (constructor)
(lambda (thunk)
(apply-values constructor
thunk))))
(define values->vector
(make-values-> vector))
Given a macro package (e.g., Extend Syntax) one can define:
(extend-syntax (multiple-value-let)
((multiple-value-let formals generator body ...)
(apply-values (lambda formals
body ...)
generator)))
(peace chance)
Morry & mas
∂28-Jul-89 1154 @mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com Regularization of apply (long)
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 28 Jul 89 11:54:11 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA00597; Fri, 28 Jul 89 14:37:17 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa16292;
27 Jul 89 19:46 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 27 Jul 89 19:46:42 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa16200;
27 Jul 89 19:39 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA03289; Thu, 27 Jul 89 19:39:25 EDT
Received: from sde.hp.com (sde.hp.com) by zurich.ai.mit.edu; Thu, 27 Jul 89 19:36:13 edt
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA18897; Thu, 27 Jul 89 16:39:07 pdt
Message-Id: <8907272339.AA18897@sde.hp.com>
Received: by hpesogg; Thu, 27 Jul 89 16:38:10 pdt
Date: Thu, 27 Jul 89 16:38:10 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: kend%mrloog.la.tek.com@relay.cs.net
Cc: rrrs-authors@zurich.ai.mit.edu, Scheme-Standard@wheaties.ai.mit.edu,
gls@think.com
In-Reply-To: kend%mrloog.la.tek.com@relay.cs.net's message of 27 Jul 89 09:27:35 PDT (Thu) <8907271627.AA08823@mrloog.la.tek.com>
Subject: Regularization of apply (long)
Reply-To: jinx%hpesogg@sde.hp.com
Your coroutines are pretty neat, but don't help me out much for
variable-arity proceedures.
(define PPRINT
(lambda*
[(<value> <port> <line-length>)
(%pprint <value> <port> <line-length>)]
[(<value> <port>)
(%pprint <value> <port> default-line-length)]
[(<value>)
(%pprint <value> (standard-output) default-line-length)]
) )
I know that you can construct code to handle such cases, but question
whether this can be compiled as efficently (given comparitive
implementation effort). Personally, I would rather have the
opportunities for optimization using multiple values and lambda* because
I think that we could do some really winning code generation.
I'm not advocating the particular details of the code that I
submitted. They were just a hint of what I would like to see.
I also feel quite strongly that the following three issues are
separable. Lambda* jumbles them up, and that is my main problem with
it:
1) Multiple values.
2) Dispatch on variable arity.
3) Acceptance of "unbounded" numbers of arguments.
I think many people agree that the current "dot notation" and apply
have some problems, but I don't think that replacing them with lambda*
solves them. The three issues above are (I think) independent, and
should be solved by independent mechanisms.
A second point is that I don't like special forms when procedures can
do the job, and all the three issues above can be solved as
efficiently by adding procedures as by adding special forms.
Special forms are syntactic cuteness that people who so desire can add
on top. Real men don't use macros :-)
∂28-Jul-89 1219 @mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com INF/SUP/MIN/MAX
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 28 Jul 89 12:18:18 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA01152; Fri, 28 Jul 89 15:00:58 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa16296;
27 Jul 89 19:46 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 27 Jul 89 19:46:55 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa16208;
27 Jul 89 19:41 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA03324; Thu, 27 Jul 89 19:40:55 EDT
Received: from sde.hp.com (sde.hp.com) by zurich.ai.mit.edu; Thu, 27 Jul 89 19:37:42 edt
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA18924; Thu, 27 Jul 89 16:40:34 pdt
Message-Id: <8907272340.AA18924@sde.hp.com>
Received: by hpesogg; Thu, 27 Jul 89 16:39:54 pdt
Date: Thu, 27 Jul 89 16:39:54 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: wand@corwin.ccs.northeastern.edu
Cc: gls@think.com, cph@zurich.ai.mit.edu, gls@think.com,
Alan@reagan.ai.mit.edu, KMP@stony-brook.scrc.symbolics.com,
RRRS-Authors@zurich.ai.mit.edu
In-Reply-To: Mitchell Wand's message of Thu, 27 Jul 89 09:30:53 ADT <8907271230.AA08188@corwin.CCS.Northeastern.EDU>
Subject: INF/SUP/MIN/MAX
Reply-To: jinx%hpesogg@sde.hp.com
[Just to make sure that everyone's archive's continue to grow quadratically, I
will follow the usual protocol of inserting an indented copy of the
correspondence up to this point.]
There are two incompatible mail file GC algorithms. :-)
The reason I copy the incoming message is that I get paranoid whenever
my mail file has more than 10 messages, therefore I flush all incoming
message. If messages did not include the message they were answering,
I would be lost, since I could not go back (conveniently) to read the
source of confusion.
∂28-Jul-89 1401 @mc.lcs.mit.edu:Alan@REAGAN.ai.mit.edu Numbers
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 28 Jul 89 14:01:30 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA02863; Fri, 28 Jul 89 16:47:42 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa17485;
27 Jul 89 21:16 EDT
Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by MC.LCS.MIT.EDU 27 Jul 89 21:16:48 EDT
Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 241995; Thu 27-Jul-89 21:15:30 EDT
Date: Thu, 27 Jul 89 21:15 EDT
From: Alan Bawden <Alan@reagan.ai.mit.edu>
Subject: Numbers
To: gls@think.com
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: <8907261612.AA01435@verdi.think.com>,
<8907261658.AA07734@verdi.think.com>,
<8907261705.AA08756@verdi.think.com>,
<19890726184151.4.KMP@BOBOLINK.SCRC.Symbolics.COM>,
<8907271433.AA07821@verdi.think.com>
Message-Id: <19890728011525.2.ALAN@PIGPEN.AI.MIT.EDU>
Date: Wed, 26 Jul 89 12:12:27 EDT
From: gls@Think.COM (Guy Steele)
...
So the main advantage of INF is that it signals an error telling me
that INF was the wrong thing, so that I can rewrite my code to use MIN
instead, right? :->
No, INF returns a result that causes an error to be signaled, so that you
can rewrite your code to avoid the overflow. You should still use INF so
that future bugs of a similar nature will be caught too!
But bucket 2148565200 *is* the last bucket. You have forgotten your
original premise:...
Quite right, I got my 10-digit numbers mixed up. I knew that the incorrect
bucket index had to be divisible by a moderate power of two (due to the
construction of the example) and then I momentarily forgot that Lisp
programmers no longer use octal all the time...
Date: Wed, 26 Jul 89 12:58:15 EDT
From: gls@Think.COM (Guy Steele)
(+ 1.0 1e20) ==> 1.0
Hm. My mom might complain about this one too. Maybe you meant
"1e-20"? Or else you got ripped off if you paid more than $2 for that
implementation.
*Cough* A typo. I hope everybody understood what I meant.
Suppose I was planning on feeding this result to MEMBER? or
ASSOC? -- isn't this just as bad as what MAX does?
No, it isn't, Alan, and here's why. Your example takes what we might
expect to be two things and makes them one....
OK, so it isn't -exactly- the same effect, but the parallel that I was
trying to draw is that you can write a piece of code that depends on the
ideal properties of the abstract function +, and you can write a program
that depends on the ideal properties of the abstract function MAX, and in
both cases you can be suprised.
I wonder, by the way, what those of you who insist that MAX must return
something EQV? to one of its arguments because "MAX computes -the- maximum
of a set of numbers", think should be the answer in the case of (MAX 1 1.0)?
Date: Wed, 26 Jul 89 13:05:35 EDT
From: gls@Think.COM (Guy Steele)
Actually, the remark that "inexact numbers just't don't behave like
numbers" prompts me to ask "are inexact numbers expected to behave like
objects"? Maybe inexact numbers should be totally excused from the
requirements of object identity. (They don't know just who they are,
so why should anyone else?) This also provides a loophole big enough
to drive a pdl-number through.
Indeed quite a large loophole. I want everyone to keep it clear that I am
-not- advocating anything like this. I am a believer in object identity
even for inexact numbers. Inexact numbers may not be "numbers" in some
sense of the word, but inexact numbers -are- objects. (They are objects
that -represent- numbers. Or perhaps more precisely, they are objects that
represent our knowledge of about certain numbers.) What we are arguing
about here is the contract of MIN and MAX, nothing more.
[ This paragraph is not addressed to Steele or any of the other current
participants in this discussion, but to casual readers of RRRS-Authors who
might read Steele's remarks here and jump to the conclusion that I am
advocating something radical that I am not. ]
Date: Wed, 26 Jul 89 14:41 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
... At least with floats the fact that games are being played is above
board, and you don't have to fail to conform in order to use standard
hardware.
... We have created a theory of numbers so strange that it's likely
that a noticeable fraction of would-be implementors will implement all
of the spec except for numbers.
I am not aware of any reasons why inexact numbers cannot be implemented
efficiently using standard floating point as the representation. The fact
that we have complicated arguments about the behavior of inexact numbers
does -not- imply that implementation of those behaviors needs to be
complicated.
Date: Thu, 27 Jul 89 10:33:25 EDT
From: gls@Think.COM (Guy Steele)
...
Incidentally, "The Brave Little Toaster" is pretty fair animation, great
storytelling for the age level it is nominally pitched at, good
characterization (given that the heroes are household appliances), and has
some fine parody sequences for us so-called grown-ups. (Maybe Alan will
have some differing opinion, and we can discuss *that* for a while. :-)
I'll agree with you on most of this. The animation did seem pretty
uninspired, but the producers clearly weren't aiming for great technical or
artistic achievement. I especially enjoyed the appliances-from-hell.
I'd give it a mild thumbs up.
∂28-Jul-89 1635 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #170
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 28 Jul 89 16:35:08 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA04585; Fri, 28 Jul 89 18:48:52 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa28077;
28 Jul 89 17:49 EDT
Date: 28 JUL 89 17:21:59 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #170
To: Scheme@mc.lcs.mit.edu
Reply-To: Scheme@mc.lcs.mit.edu
Message-Id: <8907281749.aa28077@mintaka.lcs.mit.edu>
Scheme Digest #170 28 JUL 89 17:21:59 EDT
Today's Topics:
Scheme Release 7 Beta Test
Scheme Release 7 Beta Test
Elk (Extension Language Kit) submitted to comp.sources.unix
----------------------------------------------------------------------
Date: Thu, 27 Jul 89 00:52:27 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
Message-Id: <8907270452.AA26278@zurich.ai.mit.edu>
Subject: Scheme Release 7 Beta Test
MIT Scheme release 7 is now available for beta test. This release
contains many notable changes:
* Liar, the native code compiler, is supported for 68020 and Vax
computers. Rough performance measurements indicate that it
produces code that is competitive with Orbit and Lucid Common Lisp
(although there's still some work left to beat them consistently).
High-quality debugging support is standard -- the debugger
provides nearly the same information for compiled and interpreted
code.
* Edwin, the Emacs-like text editor, is supported under curses and
X version 11. Unlike the stripped-down version supplied with TI
PC-Scheme, this is a fully-extensible editor with most of the GNU
Emacs features. Due to performance considerations it is likely to
be useful only on machines that have compiler support.
* A reference manual, written in Texinfo, is supplied. The manual
is still incomplete but even so documents a substantial part of
the system. Because it is written in Texinfo, it can be either
printed or browsed on-line with the Edwin (or GNU Emacs) info
subsystem.
* Two-dimensional line and point graphics support for X version 11
is standard. Color, border, size, and position controls are
provided.
Because this is a beta test, users should expect the installation to
be less than completely smooth. Although we have done extensive
debugging here at MIT, you should expect bugs as well. We solicit
your bug reports, criticisms, and any other comments about the
release.
A few important things are still missing, including: (1) detailed
documentation for using the compiler and editor, and (2) a
compatibility mode for S&ICP classes. We hope to remedy these, and
many other defects, by the end of August when the full release will
occur.
We've tested installation on the following machines, and would greatly
appreciate any efforts that you could make getting things running on
any other machines:
HP 9000 series 300 and 800 running HP-UX
Sun3 running SunOS
Vax running Ultrix
DS3100 running Ultrix
This release may be obtained by anonymous ftp to "zurich.ai.mit.edu"
(internet address 18.26.0.176), from the directory "pub/scheme-7.0/".
See the README file in that directory for further directions.
Because a number of people have had trouble using ftp to that machine,
we plan to distribute from a second host. When we have an alternate
host, it will be announced.
We will not be mailing tapes of this release until the beta test has
finished and the full release is out; however if you show up at MIT
with a 9-track magtape we'll be happy to put the software on it.
As usual, report bugs to
bug-cscheme@zurich.ai.mit.edu
If you receive this message from another source, and would like to be
included on the MIT Scheme mailing list, please send a request to
info-cscheme-request@zurich.ai.mit.edu
------------------------------
Date: Thu, 27 Jul 89 01:29:10 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
Message-Id: <8907270529.AA26430@zurich.ai.mit.edu>
Subject: Scheme Release 7 Beta Test
The secondary host for distribution of Scheme Release 7 is the host
"prep.ai.mit.edu" (internet address 18.71.0.38). Use anonymous ftp
and look in the directory "pub/gnu/scheme-7.0/".
At present, due to space restrictions, this secondary site carries
only the minimum required installation files. None of the optional
files for source, documentation, etc. will fit there. If feasible, we
will make the rest of the distribution available there in the future.
------------------------------
Date: 26 Jul 89 13:19:26 GMT
From: Oliver Laumann <mcvax!unido!tub!net@uunet.uu.net>
Subject: Elk (Extension Language Kit) submitted to comp.sources.unix
Message-Id: <883@tub.UUCP>
I would like to announce the posting of Elk (the Extension Language
Kit) to comp.sources.unix. Elk is a Scheme interpreter intended to be
used as a general extension language interpreter. Interfaces to the
X11R3 Xlib and the Athena and HP widget sets are part of the distribution.
This might also be of interest to the readers of comp.soft-sys.andrew
because of the recent discussion about extension languages.
Attached to this article you will find a copy of the release notes.
Regards,
--
Oliver Laumann net@TUB.BITNET net@tub.UUCP
-----------------------------------------------------------------------
Elk Release Notes
-----------------
This is release 1.0 of Elk (The Extension Language Kit).
This is a production release.
Elk is a Scheme interpreter intended to be used as a general extension
language; it is also useful as a stand-alone implementation of Scheme.
One purpose of the Elk project is to end the recent proliferation of
mutually incompatible Lisp-like extension languages. Instead of
inventing and implementing yet another extension language, application
programmers can link the Scheme interpreter into their application
in order to make it extensible and highly customizable.
The Elk project was started in 1987 to support ISOTEXT, an ODA-based
document system (a WYSIWYG editor) that is being developed at the
Technical University of Berlin. Elk has been successfully demonstrated
as the extension language kernel of ISOTEXT, e.g. at the Hanover Fair 1989.
We feel that Scheme is better suited as a general extension language
than other Lisp dialects: it is sufficiently small to not dwarf the
application it serves and to be fully understood with acceptable
effort; it is orthogonal and well-defined. In addition, Scheme has
been recognized to be mature enough for national and international
standardization (IEEE P1178, ISO/IEC JTC1/SC22/WG16).
The Elk Scheme interpreter is R↑3RS compatible (with some minor exceptions
listed in a separate document); future releases will conform to the R↑4RS
and/or P1178 as soon as the respective standards become available.
Non-standard features of the Scheme implementation include:
o dynamic loading of object files
o creation of an executable image from the running
interpreter (``unexec'')
o a macro facility
o environments as first-class objects
o dynamic-wind, fluid-let
o autoloading, provide/require
The Scheme interpreter can easily be extended by application-specific
new types and primitive procedures. Such extensions are typically
written in C or C++ and dynamically loaded into the running interpreter.
The current release of Elk includes several such extensions, e.g.
interfaces to the X11 Xlib and to the application programmer interface
of the Xt intrinsics, and interfaces to the Athena widget set and the
HP widget set.
The software currently runs on Sun-3s with SunOS, ISI 680x0 with 4.2BSD
or 4.3BSD, Vax with 4.3BSD or Ultrix, and Intel 80386 with System V
Release 3. Porting instructions are included. Dynamic loading of
object modules is not supported under System V.
--
Oliver Laumann, Technical University of Berlin, Germany
Communications and Operating Systems Research Group
net@tub.BITNET Europe: unido!tub!net World: pyramid!tub!net
------------------------------
End of Scheme Digest
********************
∂28-Jul-89 1839 @mc.lcs.mit.edu,@life.ai.mit.edu:jar@sid.stanford.edu INF/SUP/MIN/MAX
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 28 Jul 89 18:39:14 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA06202; Fri, 28 Jul 89 21:28:40 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa01127;
28 Jul 89 21:06 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 28 Jul 89 19:20:27 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa23294;
28 Jul 89 11:15 EDT
Received: from zurich.ai.mit.edu ([18.26.0.176]) by life.ai.mit.edu (4.1/AI-4.10) id AA05753; Fri, 28 Jul 89 02:04:13 EDT
Received: from mojave.Stanford.EDU (mojave.stanford.edu) by zurich.ai.mit.edu; Fri, 28 Jul 89 01:59:21 edt
Received: from Edusa.Stanford.EDU by mojave.Stanford.EDU (5.59/inc-1.0)
id AA07578; Thu, 27 Jul 89 21:25:18 PDT
Message-Id: <8907280425.AA07578@mojave.Stanford.EDU>
Received: by sid; Thu, 27 Jul 89 21:27:48 pdt
Date: Thu, 27 Jul 89 21:27:48 pdt
To: Alan@reagan.ai.mit.edu
Cc: RRRS-Authors@zurich.ai.mit.edu
In-Reply-To: Chris Hanson's message of Wed, 26 Jul 89 13:33:14 edt <8907261733.AA22254@zurich.ai.mit.edu>
Subject: INF/SUP/MIN/MAX
From: Jonathan Rees <jar%sid.stanford.edu@polya.stanford.edu>
Sender: jar@sid.stanford.edu
Date: Wed, 26 Jul 89 13:33:14 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
Just for the record, so far I agree with you Alan. I've been
following the discussion but haven't said anything because I felt you
have been making arguments at least as good as any I could.
Ditto.
∂28-Jul-89 2243 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #171
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 28 Jul 89 22:43:41 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA08719; Sat, 29 Jul 89 01:08:03 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa03596;
29 Jul 89 0:40 EDT
Date: 29 JUL 89 00:06:57 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #171
To: Scheme@mc.lcs.mit.edu
Reply-To: Scheme@mc.lcs.mit.edu
Message-Id: <8907290040.aa03596@mintaka.lcs.mit.edu>
Scheme Digest #171 29 JUL 89 00:06:57 EDT
Today's Topics:
Equivalence predicates
Inquiry about functional command shells
----------------------------------------------------------------------
Date: Fri, 28 Jul 89 15:09:46 +0200
From: Oliver Laumann <unido!tub!net@uunet.uu.net>
Message-Id: <8907281309.AA26250@tub.UUCP>
Subject: Equivalence predicates
The Revised↑n Report on Scheme does not specify the result of
eq?, eqv?, and equal? applied to ports and end-of-file objects.
Is this intentional? E.g. what is the result of
(equal? (read) (read))
provided that both reads return an end-of-file object?
Regards,
--
Oliver Laumann net@TUB.BITNET net@tub.UUCP
------------------------------
Date: 28 Jul 89 18:15:47 GMT
From: John Lacey <lacey@tcgould.tn.cornell.edu>
Subject: Inquiry about functional command shells
Message-Id: <8512@batcomputer.tn.cornell.edu>
This coming fall I am going to embark on a programming project to build a
UNIX shell based on a functional programming paradigm. My initial
inclination is to build the shell from a Lisp interpreter/compiler---options
so far include MIT Scheme, Yale T, and perhaps XScheme or the recently
mentioned ELK embedded Scheme.
The main purpose is to combine the command and programming languages of the
environment into a single system. That is, the shell language would not
only be similar to the programming language, it would _be_ the programming
language.
So far, I have found several references to similar projects, and I would
like to find further references, as well as any comments about the project
or the language that anyone might have.
The most promising reference that I have is
_fsh - A Functional UNIX Command Interpreter_,
by Chris S. McDonald
Univ. of Western Australia
It appeared in Software: Practice and Experience, 17 (10) 685-700 (1987).
If anyone knows more about this project, or has used a similar shell, I
would greatly appreciate hearing from you.
Thanks,
--
John Lacey | cornell!batcomputer!lacey
lacey@tcgould.tn.cornell.edu | lacey@crnlthry.bitnet
------------------------------
End of Scheme Digest
********************
∂30-Jul-89 1023 @mc.lcs.mit.edu,@life.ai.mit.edu:jeff%aiai.edinburgh.ac.uk@nsfnet-relay.ac.uk Re: INF/SUP/MIN/MAX
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 30 Jul 89 10:23:25 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA18884; Sun, 30 Jul 89 13:09:48 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa19972;
30 Jul 89 12:58 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 30 Jul 89 12:53:23 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa19892;
30 Jul 89 12:48 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA18799; Sun, 30 Jul 89 12:48:52 EDT
Received: from NSFnet-Relay.AC.UK (nsfnet-relay.ac.uk) by zurich.ai.mit.edu; Sun, 30 Jul 89 12:44:57 edt
Received: from aiai.edinburgh.ac.uk by NSFnet-Relay.AC.UK via Janet with NIFTP
id aa00343; 30 Jul 89 17:34 BST
Date: Sun, 30 Jul 89 17:36:25 BST
Message-Id: <11536.8907301636@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@nsfnet-relay.ac.uk>
Subject: Re: INF/SUP/MIN/MAX
To: Guy Steele <gls@think.com>, cph@zurich.ai.mit.edu
Cc: Alan@reagan.ai.mit.edu, KMP@stony-brook.scrc.symbolics.com,
RRRS-Authors@zurich.ai.mit.edu
From: Guy Steele <gls@think.com>
> Date: Wed, 26 Jul 89 15:49:33 edt
> From: cph@zurich.ai.mit.edu (Chris Hanson)
>
> [quotes Steele's arguments about Quux-head pennies, etc.]
> I don't buy these arguments: many of them have to do with side
> effects, and since when are there any side effects on numbers? So
> they don't apply.
>
> Granted. "Plus ca change, plus c'est la meme chose", as Sussman and I
> quoted in "The Art of the Interpreter". The more things change, the more
> they remain the same; that is, the notion of object identity may be linked
> to the notion of side effect. And yet, if numbers are not subject to
> side effects, in what sense can we say that 1 = 1, or that 1 /= 2 ?
I think this observation of numeric identity shows that identity can
be linked to side-effects, but also that identity doesn't require this
link. Indeed, I don't find the argument that there's some sort of
implicit potential side-effect involved in asking 1 = 1 very
convincing.
> I think that when we say 1 = 1, we are temporarily entertaining the
> possibility that the two instances of "1" represent *different* things,
> precisely so that we may then make the assertion that they are the same
> after all.
When I say "Nixon is the author of Six Crises", do this mean I'm
temporarily entertaining the possibliity that someone else wrote it?
Well, perhaps I'm at least entertaining the possibility that the
person I'm speaking to thinks so. But what if I say just "Nixon is
Nixon"? It may seem that I must have some possibility in mind that I
am trying to deny. But I don't think it's clear what this possibility
is unless I say something more. For example, I might say: "The person
you call 'Nixon' is the same person I know as 'Nixon', the author of
Six Crises, etc., and not two different people as we had once
supposed." But it's hard to see how there could be this kind of
confusion about "'1' as defined by Scheme". Indeed, it seems to me
that once we agree about what "Nixon" refers to, we can say "Nixon is
Nixon" without necessarily entertaining any possibility that Nixon
isn't Nixon.
So I don't think it's straightforward to conclude that when we
say 1 = 1, etc.
> If one of the 1's were not 1 after all, then things would be
> different, including the truth of the equality. This subjunctive
> hypothesis amounts to a side effect, for we are considering, hypothetically
> and however evanescently, a world altered from our own (whether by SETQ
> or by adding an entry to the head of an a-list).
But is every difference the result of a side-effect? Perhaps we're
just entertaining the possibility that "=" doesn't mean what we
thought it meant or that tokens like "1" refer to something different
each time.
So, I'm not sure we can take the side-effect reasoning this far.
But then I think it makes sense to talk of object identity even
when side effects are not involved, so I'm still inclined to
agree with Guy's earlier arguments.
Perhaps it would be better to use the more general notion of
"operational equivalence", though I don't know what the results
would be.
> Maybe the problem isn't the action of max or min, but eqv? If we
> considered equality as defined by = this question wouldn't come up.
> Maybe eqv? is making too fine a distinction.
>
> Indeed, and this is essentially the subject of the message I sent
> after this one (the one you replied to): maybe inexact numbers
> should not possess object identity. Please take this seriously.
> (Maybe it's the wrong idea, but it's not a frivolous idea, I think.)
I agree that we should take this suggestion seriously.
∂01-Aug-89 1716 @mc.lcs.mit.edu:hieb@iuvax.cs.indiana.edu revisiting lambda*
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Aug 89 17:16:40 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA16083; Tue, 1 Aug 89 20:07:48 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa18025;
1 Aug 89 18:46 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 1 Aug 89 17:38:27 EDT
Received: from IUVAX.CS.INDIANA.EDU by mintaka.lcs.mit.edu id aa14839;
1 Aug 89 14:46 EDT
Received: by iuvax.cs.indiana.edu
Date: Tue, 1 Aug 89 13:46:13 -0500
From: Robert Hieb <hieb@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: revisiting lambda*
Message-Id: <8908011446.aa14839@mintaka.lcs.mit.edu>
I am of course pleased to see interest in lambda* among R*S readers. At this
point lambda* has yet to see enough use---"proof of principle"---to justify its
inclusion in an established language, which is what R* Scheme has become.
However, the concepts behind it have great potential and I would like to see
them more widely experimented with. At least part of it---the dispatch on
optional arguments---is already mature enough to warrant serious consideration
as a means for handling optional arguments in R* Scheme.
I think I should respond to the ongoing critique by Rozas to make sure
budding interest is not prematurely squashed! Some interesting language design
isues which have broad applications to ongoing R*S work arise.
A summary of the relevant notes:
-------------------------------------------------------------------------------
From: Guillermo J. Rozas <jinx@hpesogg.hp.com> Tue Jul 25 19:39:34 1989
Although I agree that there are interesting issues in lambda*, I think
that lambda* mixes up too many concepts and imposes implementation
restrictions that I'm not sure I like.
I envision something more primitive, and completely different. I
think that using lists, vectors, or special values to collect and pass
arbitrary numbers of arguments is spurious. Specific data structures
should be introduced by the user according to convenience or intent.
The arbitrary arity mechanism in the language should not be based on
arbitrary data aggragates at all, but on something more primitive, and
procedures (I think) are a good choice.
-------------------------------------------------------------------------------
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com> Fri Jul 28 13:44:50 1989
I also feel quite strongly that the following three issues are
separable. Lambda* jumbles them up, and that is my main problem with it:
1) Multiple values.
2) Dispatch on variable arity.
3) Acceptance of "unbounded" numbers of arguments.
I think many people agree that the current "dot notation" and apply
have some problems, but I don't think that replacing them with lambda*
solves them. The three issues above are (I think) independent, and
should be solved by independent mechanisms.
A second point is that I don't like special forms when procedures can
do the job, and all the three issues above can be solved as
efficiently by adding procedures as by adding special forms.
Special forms are syntactic cuteness that people who so desire can add
on top. Real men don't use macros :-)
--------------------------------------------------------------------------------
Clearly Rozas agrees with the primary premise of the lamda* paper, that "using
lists, vectors, or special values to collect and pass arbitrary numbers of
arguments is spurious. Specific data structures should be introduced by the
user according to convenience or intent." However, he seems to imply that
lambda* uses "special values" to pass arbitrary numbers of values. In fact,
lambda* uses special VARIABLES to pass arbitrary numbers of values---variables
which refer to multiple values. No new sort of data structure or value was
implied.
Of more general interest is Rozas' claim that lambda* "jumbles" independent
issues which would be better handled separately. I found it notable that his
alternative approach was based on Scheme procedures in all their glory, which
"jumble" many language features which could be treated separately. Consider
some of things achieved by procedures in Scheme:
* Passing parameters.
* Returning results.
* Binding and assignment of variables.
* Scoping of variables.
* Capture of free variables (lexical scoping and indefinite extent).
* Freezing of action (procedures are a form of "potential energy").
* Passing varying numbers of parameters.
* Access to primitive data structures (the magic of cons, car, etc).
* Access to continuations (call/cc).
* Converting lists to parameters (apply).
* Converting parameters to lists (dot interface).
Yet it is certainly this "lambda jumble" that makes Scheme what it is. I think
few Schemers would want to lose any of at least the first 6 of the above
properties of Scheme procedures. The others are more debatable, but are
certainly useful in practice.
Although lambda* adds to the jumble, I think it is the best means to date for
handling procedures which accept variable numbers of arguments. Perhaps
allowing procedures with variable numbers of arguments was our first mistake,
but we must make the best of it, which was the primary goal of lambda*. The
further issue of lambda* and multiple return values is orthogonal, but once
multiple return values are added to a language it becomes necessary to
integrate them smoothly with existing features. lambda* provides solid base
for adding multiple return values, but in no way depends upon their existence.
Finally, I think there is little justification for "proceduralizing"
everything. I for one am glad that I can write (if test then else) instead
of (ef test (lambda () then) (lambda () else)). Sometimes procedures are an
appropriate way to introduce language features. cons and call/c are examples
of such procedures. But not always. I like if and I don't think procedures
like SUPPLY-ARGUMENTS and MAKE-ARGUMENTS-COLLECTOR are an improvement to the
dot interface. (I realize Rozas was not submitting them for serious
consideration, but they are the only examples of what a "procedural" solution
might look like.)
Bob
∂01-Aug-89 1731 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #172
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Aug 89 17:30:50 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA16077; Tue, 1 Aug 89 20:04:28 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa16823;
1 Aug 89 17:39 EDT
Date: 1 AUG 89 17:10:53 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #172
To: Scheme@mc.lcs.mit.edu
Reply-To: Scheme@mc.lcs.mit.edu
Message-Id: <8908011739.aa16823@mintaka.lcs.mit.edu>
Scheme Digest #172 1 AUG 89 17:10:53 EDT
Today's Topics:
Scheme Digest #171
----------------------------------------------------------------------
From: adams@daisy.cge.fr
Date: Mon, 31 Jul 89 09:39:42 +0200
Message-Id: <8907310739.AA06479@zephir.cge.fr>
Subject: Re: Scheme Digest #171
I would be quite interested in your project to write a shell etc. based
on a functional framework. I would also be interested in more info on
FSH (I remember reading the Software: Pract. & Exp. paper when it came
out). Would you please keep me posted.
Regards,
Drew ADAMS, Laboratoires de Marcoussis, Centre de Recherches de la Compagnie
Generale d'Electricite, Route de Nozay, 91460 MARCOUSSIS, FRANCE
Tel. +33 (1) 64.49.11.54, adams@crcge1.cge.fr ["one", not "ell"]
------------------------------
End of Scheme Digest
********************
∂01-Aug-89 1806 @mc.lcs.mit.edu,@life.ai.mit.edu:hal@zurich.ai.mit.edu Take Two
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Aug 89 18:06:10 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA16436; Tue, 1 Aug 89 20:57:07 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa18965;
1 Aug 89 20:12 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 1 Aug 89 19:49:40 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa15430;
1 Aug 89 15:44 EDT
Received: from zurich.ai.mit.edu ([18.43.0.179]) by life.ai.mit.edu (4.1/AI-4.10) id AA12829; Tue, 1 Aug 89 15:44:12 EDT
Received: from localhost by zurich.ai.mit.edu; Tue, 1 Aug 89 15:40:53 edt
Date: Tue, 1 Aug 89 15:40:53 edt
From: Hal Abelson <hal@zurich.ai.mit.edu>
Message-Id: <8908011940.AA10031@zurich.ai.mit.edu>
To: JMiller@crl.enet.dec.com
Cc: rrrs-authors@zurich.ai.mit.edu, Scheme-Standard@wheaties.ai.mit.edu
In-Reply-To: jmiller@crl.dec.com's message of Tue, 1 Aug 89 10:54:37 EDT <8908011454.AA01758@peanut.DEC.COM>
Subject: Take Two
Reply-To: hal@zurich.ai.mit.edu
I vote (c) -- selector semantics.
∂01-Aug-89 1810 @mc.lcs.mit.edu,@life.ai.mit.edu:jar@sid.stanford.edu Take Two
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Aug 89 18:09:53 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA16449; Tue, 1 Aug 89 20:58:42 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa19094;
1 Aug 89 20:26 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 1 Aug 89 19:53:42 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa18399;
1 Aug 89 19:30 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA15705; Tue, 1 Aug 89 19:30:44 EDT
Received: from mojave.Stanford.EDU (mojave.stanford.edu) by zurich.ai.mit.edu; Tue, 1 Aug 89 19:26:58 edt
Received: from sid.Stanford.EDU by mojave.Stanford.EDU (5.59/inc-1.0)
id AA00928; Tue, 1 Aug 89 16:27:13 PDT
Message-Id: <8908012327.AA00928@mojave.Stanford.EDU>
Received: by sid; Tue, 1 Aug 89 15:56:37 pdt
Date: Tue, 1 Aug 89 15:56:37 pdt
From: Jonathan Rees <jar@sid.stanford.edu>
To: JMiller@crl.enet.dec.com
Cc: rrrs-authors@zurich.ai.mit.edu, Scheme-Standard@wheaties.ai.mit.edu
In-Reply-To: jmiller@crl.dec.com's message of Tue, 1 Aug 89 10:54:37 EDT <8908011454.AA01758@peanut.DEC.COM>
Subject: Take Two
Date: Tue, 1 Aug 89 10:54:37 EDT
From: jmiller@crl.dec.com
P.S. -- It's long past time that things got submitted to the librarian
(jar@zurich.ai.mit.edu?). I plan to kick the ball off shortly by
taking code from MIT Scheme that is portable and submitting that. Can
others do likewise?
I'd particularly like to see a fully portable string->number that
"blows up" only when it hits an implementation restriction -- i.e. one
that will reliably produce an exact integer 3 when given "#e6/2" even
in an implementation without ratnums.....I'm not even fully convinced
that this can be done correctly without assumptions about underlying
representations.
The librarian can be reached, as always, as
scheme-librarian@zurich.ai.mit.edu.
The librarian will not be active until some time after August 20. At
that time he intends to become more active, and it is hoped that the
library wil grow in size and popularity.
∂02-Aug-89 0359 ramsdell@linus.mitre.org Re: Take Two
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 2 Aug 89 03:59:29 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA20603; Wed, 2 Aug 89 06:46:57 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA08488; Wed, 2 Aug 89 06:42:19 EDT
Posted-Date: Wed, 02 Aug 89 06:42:16 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA07091; Wed, 2 Aug 89 06:42:17 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8908021042.AA07091@huxley.mitre.org>
To: JMiller@crl.enet.dec.com
Cc: rrrs-authors@life.ai.mit.edu
Subject: Re: Take Two
In-Reply-To: Your message of Tue, 01 Aug 89 10:54:37 -0400.
<8908011454.AA01758@peanut.DEC.COM>
Date: Wed, 02 Aug 89 06:42:16 EDT
I vote (a) -- Status quo.
∂02-Aug-89 1357 @mc.lcs.mit.edu:dyb@iuvax.cs.indiana.edu Re: Take Two
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 2 Aug 89 13:56:54 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA27429; Wed, 2 Aug 89 16:41:55 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa01969;
2 Aug 89 15:56 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 2 Aug 89 15:25:55 EDT
Received: from IUVAX.CS.INDIANA.EDU by mintaka.lcs.mit.edu id aa20924;
1 Aug 89 23:30 EDT
Received: by iuvax.cs.indiana.edu
Date: Tue, 1 Aug 89 22:30:19 -0500
From: "R. Kent Dybvig" <dyb@iuvax.cs.indiana.edu>
To: JMiller@crl.enet.dec.com
Subject: Re: Take Two
Cc: rrrs-authors@mc.lcs.mit.edu
Message-Id: <8908012330.aa20924@mintaka.lcs.mit.edu>
I vote for option (c), selector semantics. I think of min and max as
conditional expressions, which I guess makes me a C weenie.
∂06-Aug-89 1352 @mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com revisiting lambda*
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 6 Aug 89 13:50:40 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA14805; Sun, 6 Aug 89 16:30:20 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa07367;
6 Aug 89 16:27 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 6 Aug 89 16:27:59 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa07354;
6 Aug 89 16:25 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA14710; Sun, 6 Aug 89 16:08:12 EDT
Received: from sde.hp.com (sde.hp.com) by zurich.ai.mit.edu; Sun, 6 Aug 89 16:04:01 edt
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA21463; Sun, 6 Aug 89 13:07:05 pdt
Message-Id: <8908062007.AA21463@sde.hp.com>
Received: by hpesogg; Sun, 6 Aug 89 13:06:26 pdt
Date: Sun, 6 Aug 89 13:06:26 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: hieb@iuvax.cs.indiana.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Robert Hieb's message of Tue, 1 Aug 89 13:46:13 -0500 <8908011446.aa14839@mintaka.lcs.mit.edu>
Subject: revisiting lambda*
Reply-To: jinx%hpesogg@sde.hp.com
[
Sorry if you receive multiple copies, but I've had some problems
mailing stuff to rrrs-authors recently.
]
However, he seems to imply that
lambda* uses "special values" to pass arbitrary numbers of values. In fact,
lambda* uses special VARIABLES to pass arbitrary numbers of values---variables
which refer to multiple values. No new sort of data structure or value was
implied.
There are two different ways to look at it. You are "blaming" the
variables, rather than the values that they hold. Ultimately you are
adding a new kind of object, or a new kind of variable, that I (and
many other people) consider unnecessary and distasteful. I also
suspect that if you try to write the semantics for it, you will find
that it is easier to think about the value being "funny", rather than
the variable.
Of more general interest is Rozas' claim that lambda* "jumbles" independent
issues which would be better handled separately. I found it notable that his
alternative approach was based on Scheme procedures in all their glory, which
"jumble" many language features which could be treated separately. Consider
some of things achieved by procedures in Scheme:
This argument is very strange. You are not trying to defend lambda*,
you are instead saying something like
"Since there is already something broken in the language, it is not
surprising that we want something even more broken, and furthermore,
how come you don't argue about the broken things already there?".
Perhaps you are trying to discredit me, rather than my argument? I
hope not.
I agree that lambda mixes up certain concepts. Both lambda* and what
I hope to see fix some of these problems. You are assuming that I'm
just being facetious by arguing against lambda* while you don't hear
me arguing against lambda. The reason I argue against lambda* is
because it is not yet in the language. Perhaps if lambda were being
considered for addition, I would be arguing against it too. That has
not been feasible since 1975. Another reason why I (and others)
haven't tried to replace lambda is that we don't have anything better,
although perhaps John Lamping's thesis points in the right direction.
After examining your list of capabilities for lambda/procedures, I
detect a basic confusion in your argument (or your interpretation of
my argument):
You must distinguish between the capabilities of procedures, and the
capabilities of the primitive forms (and procedures) that create
procedures. You don't do that.
I don't object to procedures being able to do everything. Scheme is
an applicative language, and I don't want to change that. I do object
to making each individual primitive form that creates procedures be
able to do everything. I don't want LAMBDA to become Scheme's kitchen
sink in the same way that LOOP is CommonLisp's kitchen sink (or one of
its many kitchen sinks).
Let's examine your list element by element and see whether your
objections are objections against lambda or against procedures in
general. Again, I have no objections to procedures being able to do
everything. I have objections against individual special forms (be it
lambda or lambda*) being able to do everything.
* Passing parameters.
This has nothing to do with lambda, or ultimately even with
procedures. Procedure applications (ie. combinations) pass parameters.
Procedures RECEIVE parameters. More on this below.
* Returning results.
This has nothing to do with either lambda or procedures. Expressions
"return" (or have) values. Therefore lambda expressions have values,
combinations have values, and procedure bodies have values.
Perhaps you are confusing the concept of procedures or lambda versus
their implementation with standard (procedure based) compiler technology.
* Binding and assignment of variables.
Lambda definitely binds variables, but I hardly see how it assigns
variables. Assignment is handled by set! Procedures don't bind
anything. They allocate storage for variables, and potentially mutate
the storage of preallocated variables.
* Scoping of variables.
Definitely, but this is really the same as the point about binding,
since when you have the ability to bind, you must specify how
conflicts are resolved. You are not saying anything new.
* Capture of free variables (lexical scoping and indefinite extent).
Again, this is the same point.
* Freezing of action (procedures are a form of "potential energy").
Yes. But this is a property of procedures, not (inherently) of lambda.
* Passing varying numbers of parameters.
I hope you mean receiving. Otherwise you are talking about
combinations or APPLY. If you are talking about receiving, your point
is ambiguous:
- Do you mean that procedures can accept more than one argument, ie. are
you talking about currying?
I certainly don't advocate for a curried language. I don't see any
advantage (pragmatic or aesthetic) to that.
- Do you mean that a given procedure created by lambda can accept an
unbounded number of arguments, ie. dotted parameter lists?
This point is mentioned below. At any rate, individual procedures
should certainly be able to receive any number of arguments, but it
doesn't follow that the same primitive must be used to construct all
of these procedures.
* Access to primitive data structures (the magic of cons, car, etc).
This has nothing to do with lambda.
* Access to continuations (call/cc).
Again, this has nothing to do with lambda. As an aside, I think that
the fact that "primitive" continuations are invokable is a mistake,
but it is to late to fight this battle.
* Converting lists to parameters (apply).
This has nothing to do with lambda. I still think that it is funny,
and that is what prompted my messages. Perhaps you've forgotten that.
* Converting parameters to lists (dot interface).
Both you and I are trying to fix this. Don't accuse me of defending
it.
Yet it is certainly this "lambda jumble" that makes Scheme what it is. I think
few Schemers would want to lose any of at least the first 6 of the above
properties of Scheme procedures. The others are more debatable, but are
certainly useful in practice.
As I stated before, you are confusing the power of procedures with the
capabilities of lambda. The power of procedures is what makes Scheme
what it is, not lambda per se!
Although lambda* adds to the jumble, I think it is the best means to date for
handling procedures which accept variable numbers of arguments. Perhaps
allowing procedures with variable numbers of arguments was our first mistake,
but we must make the best of it, which was the primary goal of lambda*. The
further issue of lambda* and multiple return values is orthogonal, but once
multiple return values are added to a language it becomes necessary to
integrate them smoothly with existing features. lambda* provides solid base
for adding multiple return values, but in no way depends upon their existence.
I think that lambda* was valuable in pointing out a different way of
handling dispatch on number of arguments received. There are problems
with the lambda* model, just as there are problems with the #!optional
(or &optional) model. I think that the rest argument feature is much
more questionable (and most people agreed at Snowbird), and
furthermore, I believe strongly that multiple values should be handled
by an independent mechanism. I'm not saying that lambda* is a
"waste". I'm just saying that it is no panacea, and I would like to
isolate what I consider to be its good features from what I consider
to be its bad features.
Finally, I think there is little justification for "proceduralizing"
everything. I for one am glad that I can write (if test then else) instead
of (ef test (lambda () then) (lambda () else)). Sometimes procedures are an
appropriate way to introduce language features. cons and call/c are examples
of such procedures. But not always. I like if and I don't think procedures
like SUPPLY-ARGUMENTS and MAKE-ARGUMENTS-COLLECTOR are an improvement to the
dot interface. (I realize Rozas was not submitting them for serious
consideration, but they are the only examples of what a "procedural" solution
might look like.)
I hope you mean (test (lambda () then) (lambda () else)). Besides
isn't this what IF is ultimately? :-)
This is clearly a matter of aesthetics, and yours and mine differ (not
surprising given our different backgrounds). My PERSONAL preference
is for new capabilities to be added in the form of procedures, not in
the form of special forms. Assuming that we ultimately agree on
macros (as impossible as that may seem right now), everyone can build
their own cutsey syntax on top of the "raw capability". I don't
advocate for anyone to necessarily use the primitive capabilities
directly, but I would like them to capture the essence of the concept,
and then people can abstract them away in any way they want.
The reason why I believe that capabilities should be added as
procedures, rather than syntax, is that I view syntax as a shorthand,
whose only purpose is legibility within context of the individual
program I am dealing with. Since the legibility needs of individual
programs and programmers vary, I don't like to impose any particular
shorthand or syntactic model on anyone. I believe that the
capabilities should be available by other means, and individual
programmers should map into them in whichever way they find
convenient at any point in time.
∂07-Aug-89 1734 @mc.lcs.mit.edu,@LIFE.ai.mit.edu,@zurich.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu LIST?
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 7 Aug 89 17:33:44 PDT
Received: from MINTAKA.LCS.MIT.EDU by life.ai.mit.edu (4.1/AI-4.10) id AB00489; Mon, 7 Aug 89 20:22:53 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa21088;
7 Aug 89 20:03 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 7 Aug 89 20:03:25 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa21063;
7 Aug 89 20:01 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA00247; Mon, 7 Aug 89 20:01:19 EDT
Received: from skinner.cs.uoregon.edu ([128.223.4.13]) by zurich.ai.mit.edu; Mon, 7 Aug 89 19:57:57 edt
Received: from spencer.cs.uoregon.edu by skinner.cs.uoregon.edu with SMTP
(5.59++/IDA-1.2.8) id AA04273; Mon, 7 Aug 89 17:01:01 PDT
Received: by spencer.cs.uoregon.edu; Mon, 7 Aug 89 17:01:02 PDT
Date: Mon, 7 Aug 89 17:01:02 PDT
From: will@cs.uoregon.edu
Message-Id: <8908080001.AA04985@spencer.cs.uoregon.edu>
To: rrrs-authors@zurich.ai.mit.edu
Subject: LIST?
Add LIST?.
Jim Miller:
For virtually every data type mentioned in a procedure header line in
R4RS there is either an existing predicate in the language (string?
for string, vector? for vector, rational? for q_{n}, etc.) or a
trivial piece of code (like (lambda (k) (and (integer? k) (exact? k)
(positive? k))) for k_{n}). Not so for (proper) lists referred to as
"list" in the header line. It was our intention to have P1178 make
this connection explicit, whether or not R4RS chooses to do so, and
the missing predicate for proper lists causes a problem.
We had not planned to ask RNRS to change to add such a test. But
someone else has, so I'd like to support the addition of the predicate
LIST? that tests for proper lists. I don't mind if you call it
PROPER-LIST?, but I prefer the other name, especially since the
language of the report is very clear about the definition of a list,
and it excludes both cdr-circularity and dotted tails. Another
predicate might be of interest to RnRS (NOT-TAIL-CIRCULAR? or some
such) but you won't hear me agitating to have that added to the IEEE
proposal.
Several have spoken in favor of this procedure, and none have opposed it.
There has been some debate about the name; a minority prefers PROPER-LIST?
to LIST?. The minority consists of two people, since I have changed my
mind and now prefer LIST?. To summarize that debate, LIST? is more
consistent with the terminology used in Scheme but PROPER-LIST? is more
consistent with the terminology used in Common Lisp.
I will add LIST? to the R3.99RS and R4RS as an essential procedure provided
the authors will join me in a rousing chorus of "YES, YES!". Proposed
wording:
(LIST? obj) essential procedure
List? returns #t if obj is a list of finite length, and otherwise
returns #f.
(list '(a b c)) ==> #t
(list '()) ==> #t
(list '(a . b)) ==> #f
(let ((x (list 'a)))
(set-cdr! x x)
(list? x)) ==> #f
Peace, Will
∂07-Aug-89 1756 @mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu sequential order of evaluation
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 7 Aug 89 17:56:20 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA00704; Mon, 7 Aug 89 20:41:51 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa21145;
7 Aug 89 20:09 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 7 Aug 89 20:09:34 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa21067;
7 Aug 89 20:01 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA00255; Mon, 7 Aug 89 20:01:49 EDT
Received: from skinner.cs.uoregon.edu ([128.223.4.13]) by zurich.ai.mit.edu; Mon, 7 Aug 89 19:58:28 edt
Received: from spencer.cs.uoregon.edu by skinner.cs.uoregon.edu with SMTP
(5.59++/IDA-1.2.8) id AA04280; Mon, 7 Aug 89 17:01:42 PDT
Received: by spencer.cs.uoregon.edu; Mon, 7 Aug 89 17:01:45 PDT
Date: Mon, 7 Aug 89 17:01:45 PDT
From: will@cs.uoregon.edu
Message-Id: <8908080001.AA04992@spencer.cs.uoregon.edu>
To: rrrs-authors@zurich.ai.mit.edu
Subject: sequential order of evaluation
Indeterminate order of evaluation of expressions in a procedure call.
Bill Rozas:
Any sequential order is the intention. Interleaving should not be
allowed because there are no locking primitives to serialize side
effects.
Chris Hanson:
Certainly the implementation is free to use any SEQUENTIAL order.
It has never been clear to me whether the specification permits
simultaneous evaluation of two different arguments.
Mike Shaff:
This being the case (and presuming this is the generally agreed thinking)
shouldn't this choice be made more explicit. I think the absence of said
locking primitives (at the current time) is an issue whose ramifications
should be noted.
The choice is explicit in the rather informal formal semantics, which says
the expressions must be evaluated sequentially in some permuted order.
Thus it is ok to evaluate
((f (car x)) (g (car x)))
as though it were
(let* ((t1 (f (car x)))
(t2 (g (car x))))
(t1 t2))
or
(let* ((t2 (g (car x)))
(t1 (f (car x))))
(t1 t2))
but it is not ok to evaluate it as though it were
(let* ((t0 (car x))
(t1 (f t0))
(t2 (g t0)))
(t1 t2))
or
(let* ((t0 (car x))
(t2 (g t0))
(t1 (f t0)))
(t1 t2)).
The problem with saying that the evaluation must be sequential is that the
word "sequential" isn't very well-defined. Some people think only the first
of the four is sequential, and some think all four are sequential.
How do the authors feel about adding the following note to section 4.1.3?
Note: Although the precise order of evaluation is unspecified, the
expressions must be evaluated without interleaving. Interleaving is
not allowed because Scheme provides no facilities for serializing
concurrent side effects.
∂07-Aug-89 1949 @mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu R3.99RS issues (long message)
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 7 Aug 89 19:49:14 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA01437; Mon, 7 Aug 89 22:30:28 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa21149;
7 Aug 89 20:09 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 7 Aug 89 20:09:53 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa21076;
7 Aug 89 20:03 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA00266; Mon, 7 Aug 89 20:03:03 EDT
Received: from skinner.cs.uoregon.edu ([128.223.4.13]) by zurich.ai.mit.edu; Mon, 7 Aug 89 19:59:41 edt
Received: from spencer.cs.uoregon.edu by skinner.cs.uoregon.edu with SMTP
(5.59++/IDA-1.2.8) id AA04281; Mon, 7 Aug 89 17:02:51 PDT
Received: by spencer.cs.uoregon.edu; Mon, 7 Aug 89 17:02:53 PDT
Date: Mon, 7 Aug 89 17:02:53 PDT
From: will@cs.uoregon.edu
Message-Id: <8908080002.AA05003@spencer.cs.uoregon.edu>
To: rrrs-authors@zurich.ai.mit.edu
Subject: R3.99RS issues (long message)
No less than 12 issues, by my count, have been debated here since I lost
contact with the net. I'll be responding to some of them separately. For
the others, this message summarizes my perception of the consensus or lack
thereof for purposes of the R4RS.
William Clinger
--------------------------------------------------------------------------------
Timing of the R3.99RS, R4RS.
Mike Shaff:
I am definitely in favor of moving forward on issues and getting the
report out to the public, however the latest version of the report that
I have (via zurich) still seems to have some areas that I thought were to
be part of the document (per L&FP such things as macros, name
regularization, etc were to be 'rubber stamped' by the group). Is there
to be another beta release *before* the submission to P1178? If not, what
happened to those and other favorites?
There will not be a beta release before submitting R3.99RS to P1178 because
there isn't time if P1178 is to circulate a draft IEEE standard before its
next meeting. Matters for which we have not reached consensus will have
to wait for the R5RS. There were only two things that the Snowbird meeting
"rubber stamped" in advance: clarification of the numeric procedures, and
macros. On the matter of regularization, it was agreed that Morry Katz would
develop a proposal for consideration over the net, but the Snowbird meeting
did not commit itself to accepting such a proposal.
With regard to the numeric procedures, we appear to have reached consensus
on everything except MIN and MAX; at worst I can leave MIN and MAX out of
the R4RS, but I expect we will do better than that. The macro committee
has thus far failed to agree on a proposal. The plan is for the R4RS (but
not the R3.99RS) will have an appendix that describes (at least) two
incompatible macro proposals and the issues that have prevented them from
being resolved; this should be the only substantial difference between the
R3.99RS and the R4RS. We do not have consensus on wholesale regularization,
but some regularization is occurring anyway (see below).
Pavel Curtis:
I'd rather that we did not cut off debate on R4RS at the end of this
month. It seems to me that there are several reasonably important
issues currently on the table that could make it into R4RS in the very
near future (e.g., uniform definition semantics, fluid binding, and
regularization of procedures). I would hate to see R4RS come out so
little changed from the previous report; in a sense, what's the point?
The point is that there should be a version of the RnRS that corresponds to
the P1178 draft. The P1178 committee has committed itself to follow the RnRS,
not to lead it. The changes that Pavel mentions are upwardly compatible with
what will be in the R4RS, so there's no reason to delay the R4RS on their
account.
--------------------------------------------------------------------------------
Flushing ELSE.
Morry Katz:
....I therefore advocate that we remove ELSE from the list of syntactic
keywords and replace ELSE by #T in the COND examples in RNRS....
This proposal has not attracted support, and is about to die for lack of a
second.
--------------------------------------------------------------------------------
Fluid variables or cells.
There seems to be agreement in principle but little consensus on details.
I think this is a good topic for R5RS but not for R4RS.
--------------------------------------------------------------------------------
FORCE and DELAY.
Mike Shaff:
Force and delay are currently in totally separate sections of R3.95RS
which can lead readers to hours of fun and enjoyment. Perhaps the
Delayed Evaluation section (4.2.5) can be made a subsection of Control
Features (6.9) and expanded to include force.
Sections 4.2.5 and 6.9 refer to each other explicitly. I can see how this
might cause a minute or two of page-flipping, but I think only a very
creative reader could derive hours of fun and enjoyment from it.
--------------------------------------------------------------------------------
Add CONTINUATION?
This issue has been withdrawn. In the message withdrawing this issue, Morry
Katz said:
I believe that PROCEDURE? is a serious misnomer. The function should
really be called APPLICABLE?.
All applicable objects described in R4RS are procedures, and vice versa, so
PROCEDURE? is no more a misnomer than APPLICABLE?. The name has been
debated twice in the last five years, and PROCEDURE? has won out both times.
--------------------------------------------------------------------------------
EQV? on numbers.
Jim Miller:
I thought that
(and (number? x) (number? y) (= x y)) implied
(eqv? x y).
By my reading of R3.95RS this isn't true (consider x=3 and y=3.0),
although I believe
(and (number? x) (number? y) (eqv? x y)) implies
(= x y)
Have I got this right?
Yes. In fact, my reading is that
(and (number? x) (number? y) (eqv? x y))
is equivalent to
(and (number? x) (number? y) (eqv? (exact? x) (exact? y)) (= x y)).
Pavel Curtis:
I would be unhappy with any statement that distinguished between the
behavior of, for example, the car cell of a pair and the contents of a
lexical variable...
The discussion at the recent P1178 meeting addressed both, though this
may not have been reflected by the minutes.
In my separate message on MAX and MIN, I argue that the requirement that
EQV?-ness be preserved should not be strengthened to a requirement that
EQ?-ness be preserved. I will expand that argument if people want me to.
--------------------------------------------------------------------------------
Add bitwise logical operation on exact integers (bitvectors, whatever).
This sounds like an excellent proposal for the yellow pages, and later for
inclusion in R5RS.
--------------------------------------------------------------------------------
Require left-to-right evaluation of internal definitions.
Pavel Curtis:
Given your retraction of this objection and John's and my unanswered
refutations of your first one, may we assume that you now support the
proposal to unify definition semantics? If not, could you say more?
I remember that you sent some messages denying my first objection, but I
don't recall any refutations of it.
I still prefer that the order of evaluation of internal definitions be left
unspecified, for the same reason that the order of evaluation of arguments
in a procedure call is unspecified. In both cases the context is such that
the order of evaluation ordinarily would not matter even if it were
specified. By leaving the order of evaluation unspecified, we save the
reader of a correct program from having always to consider the remote
possibility that the order is significant.
The obvious "disadvantage" of leaving the order unspecified is that people
who want to use side effects cannot use a tacit sequencing implicit to the
internal definitions or arguments, but must use an explicit BEGIN instead.
I maintain that this is actually the great advantage of leaving the order
unspecified.
The real disadvantage of leaving the order of evaluation unspecified is that
it becomes easier to write incorrect code. In my opinion this has not been
an important problem.
An aesthetic disadvantage in the case of internal definitions is that the
order of evaluation *is* specified for top-level definitions. I maintain
that this inconsistency results from our current compromise with file-based
program structures and separate compilation---matters that aren't even
mentioned in the Report, but influence it regardless. I too would like to
remove this inconsistency, but would prefer to fix it by removing the
implicit sequencing of top-level definitions. I hope this will be possible
in a future module facility or other extension for programming-in-the-large.
For all that, I repeat my earlier statement that I am not strongly opposed
to requiring that internal definitions be evaluated from left to right.
I am merely opposed. I will certainly implement this change if the authors
want me to.
--------------------------------------------------------------------------------
Why aren't more procedures required to return exact integers more often?
Alan Bawden:
Actually, I'd be more interested to know what -isn't- on the list. I'll
bet SQRT isn't there because people think that SQRT of an exact 4 should be
allowed to return something inexact rather than an exact 2. Am I right?
I suspect that if I understood more about this "list" I would argue that
-all- numeric functions belonged on it (including SQRT).
Bill Rozas:
Correct. I suppose it's a matter of practicality -- nobody wanted to
commit to implement `sqrt' to handle this case specially, presumably
because such behavior isn't too interesting. To take it further, I
suppose it wouldn't hurt to add the transcendental functions to the
list....The only good reason why `/' and `sqrt' should not be in the
list is efficiency and implementation complexity. Maybe that's not
good enough....
I suspect that there's no argument for keeping the transcendental
functions out of the list since my intuition tells me that there is no
case where integer arguments provide an integer result; if there is
such a case, it's probably pretty obscure...A similar argument holds
for `make-polar' and `angle'....
Here's the cases I could think of that would require special treatment:
(exp 0), (log 1), (sin 0), (cos 0), (tan 0), (asin 0), (acos 1), (atan 0),
(atan 0 n), (make-rectangular n 0), (make-polar n 0), (angle n),
(magnitude n); where n is an exact but not necessarily non-negative
integer.
Summary: the only procedures that seem to matter are `/' and `sqrt',
and the argument in favor of excluding them is pragmatic.
Scheme would be simpler if we could just say that with the exception
of EXACT->INEXACT, all procedures in section 6.5 that return a numeric
result will return an exact integer result provided all their arguments
are exact integers and the mathematically expected result is representable
as an exact integer within the implementation.
I think the argument in favor of simplicity outweighs the pragmatic
argument, partly because the pragmatic argument is weak. It isn't very
hard to handle the special cases, and it's unlikely that SQRT needs to be
particularly fast on exact integers. I propose that we make this change
in R5RS.
Peace, Will
∂07-Aug-89 2002 @mc.lcs.mit.edu,@LIFE.ai.mit.edu,@zurich.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu MIN and MAX (long message)
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 7 Aug 89 20:02:10 PDT
Received: from MINTAKA.LCS.MIT.EDU by life.ai.mit.edu (4.1/AI-4.10) id AB01536; Mon, 7 Aug 89 22:47:57 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa21252;
7 Aug 89 20:16 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 7 Aug 89 20:16:23 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa21158;
7 Aug 89 20:09 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA00343; Mon, 7 Aug 89 20:09:54 EDT
Received: from skinner.cs.uoregon.edu ([128.223.4.13]) by zurich.ai.mit.edu; Mon, 7 Aug 89 20:06:31 edt
Received: from spencer.cs.uoregon.edu by skinner.cs.uoregon.edu with SMTP
(5.59++/IDA-1.2.8) id AA26857; Mon, 7 Aug 89 16:02:43 PDT
Received: by spencer.cs.uoregon.edu; Mon, 7 Aug 89 16:02:42 PDT
Date: Mon, 7 Aug 89 16:02:42 PDT
From: will@cs.uoregon.edu
Message-Id: <8908072302.AA04327@spencer.cs.uoregon.edu>
To: rrrs-authors@zurich.ai.mit.edu
Subject: MIN and MAX (long message)
I agree with almost everything Alan Bawden and Mitch Wand have said
concerning MIN and MAX, so I will try to avoid repeating their
arguments in this note. The purpose of this note is to argue:
* Although the concept of exactness is a new and useful idea, it
is not a radical new idea. Programmers who naively assume that
inexact numbers are just another name for floating point numbers
are unlikely to get into any trouble they wouldn't already be in
with floating point. Furthermore the concept of exactness does
not entail any loss of efficiency.
* The controversy concerning the semantics of MIN and MAX has nothing
to do with the fact that Scheme does not require inexact numbers to
be represented in floating point format. It has to do with the
relationship between exact and inexact numbers (by whatever names
you want to call them) in a generic arithmetic system.
* No major programming language adopts either semantics that we are
considering for MIN and MAX. In particular, I think Guy was pulling
our collective leg when he claimed that MIN and MAX act as
conditionals in C.
* Certain statements that have been made in this discussion deserve
correction, qualification, or elaboration.
--------------------------------------------------------------------------------
Alan Bawden:
I've never heard users asking for the notion of exactness/inexactness at
all. Ask them what they want, and they will probably tell you that they
want IEEE floating point. As I have said before, I think it would be 100%
reasonable for Scheme to do what every other language does, and adopt some
reasonable set of rules for the behavior of floating point. Unfortunately,
Scheme decided to go in a different direction....
You might be shocked by how little "every other language" has to say about
what floating point is and how it behaves. A lot of machines don't support
IEEE floating point very well, so language designers have to be pretty vague
about floating point if they want their language to run well on popular
hardware.
At Brandeis we asked ourselves what was distinctive about floating point,
and why we needed it. The answer was that floating point was inexact, and
we needed it for efficient (though approximate) calculations with real
numbers. Instead of writing a vague description of how floating point
arithmetic behaves in Scheme, we wrote a vague description of how
inexact arithmetic behaves.
Although the Scheme report explicitly recognizes that non-floating-point
implementations of inexact arithmetic are possible, I suspect that most
language standards are vague enough that non-floating-point implementations
of their "real" or "float" types would be just as legal as in Scheme. So
I don't think we've done anything radical by allowing non-floating-point
implementations of inexact arithmetic.
Furthermore I don't think many programmers would notice the difference if
a good non-floating-point implementation of inexact numbers were used.
People doing serious calculations would notice and gripe, but they might
gripe about IEEE arithmetic as well (because, for example, its roundoff
characteristics are different from those of the Cray their programs have
been written for). If people doing serious calculations have technical
complaints about the non-floating-point implementation, well, maybe the
implementors should listen to them. (Now that would be radical!)
Kent Pitman:
....If Scheme numbers are to persist
in their current form, I would like to be able to speak as confidently
about their demonstrated usefulness, and I don't now feel that I have
the ammunition to do so.
Here are four benefits, arranged in decreasing order of importance by
my estimate. The basic argument in favor of the R3.95RS semantics for
MIN and MAX is that any other semantics would weaken the most important
benefit by adding yet another hypothesis.
* If a calculation yields an exact result, and the calculation did
not involve any predicates on inexact numbers, and did not call
INEXACT->EXACT, then the result is correct.
* The rules for calculating with exact numbers are such that the
extra hypotheses in the sentence above can often be checked
statically.
* The integers are a subset of the rationals, which are a subset of
the reals, which are a subset of the complex numbers.
* The ODD?, EVEN?, QUOTIENT, REMAINDER, MODULO, GCD, LCM, NUMERATOR,
and DENOMINATOR procedures accept inexact as well as exact
arguments.
Kent Pitman:
....It would be one thing if it -also-
provided floats, so that people could get real work done while they
waited for the other stuff to get field tested, but my own cynical
viewpoint is that--for quite a while yet, anyway-- implementations are
likely to be either correct or efficient, but not both. At least with
floats the fact that games are being played is above board, and you
don't have to fail to conform in order to use standard hardware.
Since floating point is not only a permitted representation for inexact
numbers but is in fact the typical representation, I don't understand
this argument at all. Arithmetic in Scheme is as efficient as generic
arithmetic in, say, Common Lisp.
I agree that it will take a year or two for people to get the bugs out
of their systems. In MacScheme 2.02, for example, the comparison
operators aren't transitive yet, the NUMBER->STRING, STRING->NUMBER, and
EXACT->INEXACT procedures aren't always good to the last bit, and the
MIN and MAX procedures still act as selectors. These are the only
arithmetic bugs I know of, six months after product release. None have
to do with exactness or inexactness, since they would remain bugs even
if Scheme were to require floats instead of inexact numbers.
Guy Steele Jr:
...every C weenie has the formula
#define max(x,y) ((x) > (y)) ? (x) : (y)
engraved in his little weenie brain. See? MAX really is a conditional.
I'm not much of a C weenie, and I don't have a description of the
proposed (or actual?) ANSI standard, but I think I know enough C to
suspect that Guy didn't mean for us Scheme weenies to take this seriously.
When examined more closely, Guy's example shows that C weenies think more
like me than like Guy. (This doesn't surprise me, unfortunately.)
C is a statically typed language, with very little polymorphism, that
regards ints and floats as different types. (I'm going to speak as
though all the different integer types were collapsed into one type, and
all the different float types into one type.) The two alternatives of
a conditional expression must have the same type, or else be convertible
to the same type using C's conversion rules. If you define max as Guy
suggested and then write max(2.5, 1000) as an expression, then the result
of that expression will be a float (1000.0), not an int.
If you write max(2.5, 1000) in a context that expects an int, then the
floating point 1000.0 will be converted back into an int (1000). (It
isn't wise to regard that conversion as part of the expression's
semantics, because you would then have to believe that max(2, 1000.5)
also evaluates to an int.) Hence max(2.5, 1000) in an int context is
really the equivalent of (INEXACT->EXACT (TRUNCATE (MAX 2.5 1000))) in
Scheme.
So if MAX really is a conditional in C, then (MAX 2.5 1000) ==> 1000.0
is consistent with MAX being a conditional. It seems that Guy's example
actually supports the R3.95RS semantics he was arguing against.
To my knowledge, no major programming language defines MAX so that
MAX of a floating point 2.5 and an exact integer 1000 is guaranteed
to be an (exact) integer. Common Lisp, which explicitly leaves it up
to the implementation, comes the closest. [My original posting to the
effect that Common Lisp requires (MAX 2.5 1000) to be 1000.0 was
incorrect, as Guy pointed out.]
With most C compilers, it is true that the result of max(x, y) will
always be equal to one of the arguments. This essentially results
from the poverty of C's representations. The R3.95RS semantics of
MAX allows this property to be achieved in Scheme the same way it
is achieved by C:
* Don't implement exact arithmetic for any types except integers.
* Limit the range of exact integers to +-9007199254740992.
(Any smaller range will work too.)
* Represent inexact reals as IEEE 64-bit floats.
Hence one could say that the R3.95RS semantics, like Common Lisp, allows
(but does not require) MAX to return a result that is not equal to any
of its arguments---but it would be misleading. [Apologies to RMN.]
Guy Steele Jr:
(1) I see no reason why the rules of inexact contagion should
apply to MAX. As Pavel has observed, >= does not return an
inexact boolean. (If >= were to be three-valued (yes/no/maybe)
then it would be more consistent.)
MIN and MAX don't return booleans. With the R3.95RS semantics, my
faith in an exact result is threatened only by predicates and by
INEXACT->EXACT. I'm not happy about having to remember those
exceptions, but I'd be even less happy if I had to remember them as
"predicates, INEXACT->EXACT, MIN, and MAX". The predicates and
INEXACT->EXACT are pretty easy to remember because they seem so
inevitable, but MIN and MAX would look like they made the list
because someone hadn't been thinking very clearly.
I'm not convinced by the argument that MIN and MAX are mere comparisons,
not computations, possibly because I know how much computation a mere
comparison is likely to take in Scheme when one argument is exact and
another inexact.
Alan Bawden:
....If the multiplication overflows the range of exact integers in
some implementation and returns an inexact, then the division will
return an inexact as well, and then VECTOR-REF will signal an error....
Guy Steele Jr:
Depends on why I put the MIN in there. If I put it in precisely to
guard against indexing off the end of the vector when running in
broken implementations that think 32 bits is enough to count anything
interesting at all, then the program is doing its job, and MIN is
exactly what I wanted.
VECTOR-REF isn't guaranteed to signal an error if its second argument is
inexact. Section 1.3.2 says "Implementations may extend a procedure's
domain of definition to include such arguments".
Will Clinger:
...e.g. (MAX 1.4 #e1e100) ==> 9.999999999999998e99.
Bill Rozas:
As far as I understand it (and GJS agrees with me), the example Will
shows could only be correct in an implementation where
(>= 9.999999999999998e99 #e1e100) is true. If it isn't, the
implementation of MAX/SUP is in error.
Not as I understand it. I intended for this example to illustrate
what happens in an implementation that uses IEEE 64-bit floating
point to represent inexact reals, but I goofed (because of a bug
in the least significant bit of MacScheme's implementation of
EXACT->INEXACT for large numbers). A better example is
(MAX 1.4 #e1e200) ==> 9.99999999999999969733e199
I think this example is correct in the implementation described, even
though (>= 9.99999999999999969733e199 #e1e200) is false. The entire
specification of MAX and MIN is that they "return the maximum or minimum
of their arguments", but the implementation described will be unable to
meet this spec because it doesn't have enough precision to represent
10↑200 as an inexact number without loss of accuracy. The implementation
has exactly the same problem with + and *, which are supposed to "return
the sum or product of their arguments" but can't in examples like
(+ 1.5 1e-30). In such cases "it is the duty of each implementation
to make the result as close as practical to the mathematically
ideal result". It happens that 9.99999999999999969733e199 is the
inexact number that is closest to 10↑200 in this implementation.
The next closest inexact number is 1.00000000000000013969e200,
which is apparently the result desired by Rozas and GJS:
...A good implementation would coerce to floating point
rounding towards infinity (ie. add 1 at the least significant
mantissa bit after truncating the bits) in order to return a
value >= than all the inputs.
This isn't obvious, and I think it's untrue. The property you
desire (that the result be greater than or equal to all inputs)
is in conflict with another nice property, namely that the result
of MAX be as close as possible to the mathematically ideal result.
Something has to give.
I think that requiring MAX to round up would be like requiring
(+ x y) to return a number greater than x whenever y is positive.
It sounds plausible at first, but would tend to make computations
less accurate. I have to admit, given the difficulty of coming up
with any real-world examples where MAX returns a value that is not
equal to one of its arguments, that a difference in the least
significant bit in such cases would probably be of very little
consequence, and it might make someone's mother happy.
Jim Miller:
(a) They are selectors from a set of numbers and thus there is
a legitimate expectation that (memq (max <set>) <set>) ==>
#t. (Yes, I DO mean memq not memv.)
I think you should have meant MEMV, not MEMQ. There is only one reason
why EQ? is in Scheme at all: it is an efficiency hack for performing an
EQV? comparison when one of the arguments is known to be of a type for
which EQ? coincides with EQV?. Consider these facts: The EQ? procedure
is nothing but a more implementation-dependent version of EQV?. It is
perfectly legal for an implementation to make EQ? be exactly the same
procedure as EQV?. It is also legal for EQ? to return #F whenever it is
passed a number or a character. EQ? is, in short, a real crock whose
role we should be eliminating rather than expanding.
(The fact that EQ? is permitted to be universally false when passed a
number or character would not be affected by the R3.99RS's new requirement
that EQV?-ness must be preserved by storing and fetching from data
structures. Strengthening this to preservation of EQ?-ness would decrease
the performance of some Scheme implementations, which could only be
justified by some offsetting benefit. The efficiency argument against
preserving EQ?-ness cannot simply be dismissed, because efficiency is also
the only argument in favor of having EQ? in the language. The only
important objects for which EQ? can differ from EQV? are numbers,
characters, and empty strings and vectors, so any benefits obtained from
preserving EQ?-ness as well as EQV?-ness must turn on the desirability
of making EQ? more reliable on these objects. It will be hard to argue
that EQ? needs to be more reliable on these objects, because anyone who
thinks they need the additional reliability could just use EQV? instead.)
Guy Steele Jr:
....maybe inexact numbers should not possess object identity.
The behavior of EQ? on numbers (exact or inexact) is unspecified,
except that it must always return a boolean and (EQ? x y) implies
(EQV? x y). The behavior of EQV? on numbers is defined in terms
of = and EXACT?. It therefore seems to me that Scheme numbers in
general already lack object identity, unless what you mean by that
is either (1) you want calling EQ? or EQV? on an inexact number to
be an error; or (2) you want the Scheme procedure = to be unspecified
or erroneous on inexact numbers.
Alan Bawden:
....I am a believer in object identity even for inexact numbers....
I haven't the slightest idea what you are talking about, and it makes
me feel like Michael Dukakis. Could somebody please tell me what
object identity is, and why it inspires such passionate allegiance?
Jim Miller:
(e) None of the above. Please state your position.
See page 33 of "'Toons for our Times" by Berke Breathed.
Peace, Will
∂07-Aug-89 2206 @mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu LIST?
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 7 Aug 89 22:06:15 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AB02881; Tue, 8 Aug 89 00:55:06 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa21779;
7 Aug 89 21:00 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 7 Aug 89 21:00:49 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa21713;
7 Aug 89 20:53 EDT
Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA00782; Mon, 7 Aug 89 20:52:54 EDT
Received: from localhost by zurich.ai.mit.edu; Mon, 7 Aug 89 20:49:35 edt
Date: Mon, 7 Aug 89 20:49:35 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
Message-Id: <8908080049.AA00201@zurich.ai.mit.edu>
To: will@cs.uoregon.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: will@cs.uoregon.edu's message of Mon, 7 Aug 89 17:01:02 PDT <8908080001.AA04985@spencer.cs.uoregon.edu>
Subject: LIST?
Date: Mon, 7 Aug 89 17:01:02 PDT
From: will@cs.uoregon.edu
I will add LIST? to the R3.99RS and R4RS as an essential procedure provided
the authors will join me in a rousing chorus of "YES, YES!".
Yes.
∂07-Aug-89 2216 @mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com LIST?
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 7 Aug 89 22:15:41 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA02909; Tue, 8 Aug 89 01:00:55 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id ab21998;
7 Aug 89 21:17 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 7 Aug 89 21:18:10 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa21817;
7 Aug 89 21:06 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA00924; Mon, 7 Aug 89 21:06:44 EDT
Received: from sde.hp.com (sde.hp.com) by zurich.ai.mit.edu; Mon, 7 Aug 89 21:03:22 edt
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA01112; Mon, 7 Aug 89 18:06:26 pdt
Message-Id: <8908080106.AA01112@sde.hp.com>
Received: by hpesogg; Mon, 7 Aug 89 18:05:48 pdt
Date: Mon, 7 Aug 89 18:05:48 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: will@cs.uoregon.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: will@cs.uoregon.edu's message of Mon, 7 Aug 89 17:01:02 PDT <8908080001.AA04985@spencer.cs.uoregon.edu>
Subject: LIST?
Reply-To: jinx%hpesogg@sde.hp.com
I will add LIST? to the R3.99RS and R4RS as an essential procedure provided
the authors will join me in a rousing chorus of "YES, YES!". Proposed
wording:
(LIST? obj) essential procedure
List? returns #t if obj is a list of finite length, and otherwise
returns #f.
(list '(a b c)) ==> #t
(list '()) ==> #t
(list '(a . b)) ==> #f
(let ((x (list 'a)))
(set-cdr! x x)
(list? x)) ==> #f
(let loop ()
(newline)
(display "Yes, Yes!")
(loop))
∂07-Aug-89 2237 cph@zurich.ai.mit.edu Scheme Digest #174
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 7 Aug 89 22:37:18 PDT
Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA02907; Tue, 8 Aug 89 01:00:27 EDT
Received: from localhost by zurich.ai.mit.edu; Tue, 8 Aug 89 00:57:09 edt
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.mc.lcs.edu>
Sender: cph@zurich.ai.mit.edu
To: scheme-inbox@life.ai.mit.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.mc.lcs.edu
Message-Id: <8908070017.aa10696@mintaka.lcs.mit.edu>
Date: 7 AUG 89 00:02:32 EDT
Subject: Scheme Digest #174
Scheme Digest #174 7 AUG 89 00:02:32 EDT
Today's Topics:
"Scheme has data types and Lisp doesn't."
----------------------------------------------------------------------
Date: 6 Aug 89 18:55:51 GMT
From: Bruce Smith <thorin!evergreen!bts@mcnc.org>
Subject: Re: "Scheme has data types and Lisp doesn't."
Message-Id: <9085@thorin.cs.unc.edu>
I hope someone here can explain the origin of this notion that
"Scheme has data types and Lisp doesn't". I have heard several
people make this claim over the past couple of years, but never
with any concrete evidence nor even a clear explanation of what
it's supposed to mean. (It was usually in almost exactly those
words, however.)
I know a modest amount about these languages and have access to
references on them. I have not been able figure out what it is
supposed to mean.
Most recently, in a discussion of which functional programming
language should be taught to students (not at UNC, by the way)
I heard that Scheme was to be preferred because compiled Scheme
executes much faster than compiled Common Lisp. The reason for
that difference? Because, of course, "Scheme has data types
and Lisp doesn't."
------------------------------
End of Scheme Digest
********************
∂08-Aug-89 0015 @mc.lcs.mit.edu,@zermatt.lcs.mit.edu:ziggy@hx.lcs.mit.edu RE: sequential evaluation of arguments
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 8 Aug 89 00:15:22 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA00254; Tue, 8 Aug 89 02:59:21 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22442;
7 Aug 89 22:03 EDT
Received: from ZERMATT.LCS.MIT.EDU (CHAOS 17316) by MC.LCS.MIT.EDU 7 Aug 89 22:03:25 EDT
Received: from HX.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via INTERNET with SMTP id 280341; 7 Aug 89 22:03:14 EDT
Received: by hx.LCS.MIT.EDU (5.51/4.7); Mon, 7 Aug 89 22:01:54 EDT
Message-Id: <2827533780-14096492@RTS-8>
Sender: ziggy@rts-8.lcs.mit.edu
Date: Mon, 7 Aug 89 22:03:00 EDT
From: "Michael R. Blair" <ziggy@hx.lcs.mit.edu>
To: rrrs-authors@zermatt.lcs.mit.edu
Subject: RE: sequential evaluation of arguments
Note: Although the precise order of evaluation is unspecified, the
expressions must be evaluated without interleaving. Interleaving is
not allowed because Scheme provides no facilities for serializing
concurrent side effects.
Isn't this a bit strong? Specifically, saying that exprs MUST BE EVALUATED
WITHOUT INTERLEAVING precludes parallel implementations which do compile-time
side-effect analysis to determine that two expressions' side effects are
non-interferring and thus can safely be run concurrently. (Note that within
this context, we would consider two calls to CONS to "interfere" in the sense
that they have ALLOCATE effects, the results of which may not be shared, just
as we would consider two calls to I/O routines on the same I/O port to
interfere).
A more forgiving wording might be "expressions must be evaluated without
DETECTABLE interleaving" or "expressions must be evaluated in an order
consistent with some non-interleaved evaluation. Detectable interleaving is
not allowed because Scheme provides no facilities for serializing concurrent
interferring side-effects." I emphasize interferrence since that is the real
concern: one shouldn't care about serializing non-interferring side-effects.
To point, it would be nice to allow common sub-expression ellimination of
pure expressions, such as:
(let* ((x (f (moby-expensive-number-crunch 3.1415)))
(y (g (moby-expensive-number-crunch 3.1415))))
(h x y))
==
(let* (($$ (moby-expensive-number-crunch 3.1415))
(x (f $$))
(y (g $$)))
(h x y))
My understanding of the Note at the top is that this would be forbidden.
It would be a shame to banish "sufficiently clever" compilers for parallel
machines to the realm of non-Scheme.
Am I just being an alarmist? ~Ziggy
∂08-Aug-89 0241 @mc.lcs.mit.edu,@zermatt.lcs.mit.edu:jinx@hpesogg.hp.com sequential evaluation of arguments
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 8 Aug 89 02:41:44 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA00786; Tue, 8 Aug 89 05:29:45 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa26224;
8 Aug 89 3:55 EDT
Received: from ZERMATT.LCS.MIT.EDU (CHAOS 17316) by MC.LCS.MIT.EDU 8 Aug 89 03:56:20 EDT
Received: from SDE.HP.COM by ZERMATT.LCS.MIT.EDU via INTERNET with SMTP id 280383; 8 Aug 89 03:56:07 EDT
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA15625; Tue, 8 Aug 89 00:54:59 pdt
Message-Id: <8908080754.AA15625@sde.hp.com>
Received: by hpesogg; Tue, 8 Aug 89 00:54:21 pdt
Date: Tue, 8 Aug 89 00:54:21 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: ziggy@hx.lcs.mit.edu
Cc: rrrs-authors@zermatt.lcs.mit.edu
In-Reply-To: "Michael R. Blair"'s message of Mon, 7 Aug 89 22:03:00 EDT <2827533780-14096492@RTS-8>
Subject: sequential evaluation of arguments
Reply-To: jinx%hpesogg@sde.hp.com
Note: Although the precise order of evaluation is unspecified, the
expressions must be evaluated without interleaving. Interleaving is
not allowed because Scheme provides no facilities for serializing
concurrent side effects.
Isn't this a bit strong? Specifically, saying that exprs MUST BE EVALUATED
WITHOUT INTERLEAVING precludes parallel implementations which do compile-time
side-effect analysis to determine that two expressions' side effects are
non-interferring and thus can safely be run concurrently. (Note that within
this context, we would consider two calls to CONS to "interfere" in the sense
that they have ALLOCATE effects, the results of which may not be shared, just
as we would consider two calls to I/O routines on the same I/O port to
interfere).
Being a firm believer in Quantum Mechanics, I believe that if you
can't tell the difference, you can do anything you want. I think you
are interpreting the wording too restrictively. I interpret all such
"commands" as saying "your implementation must produce the same values
as if...", not "your implementation must act in exactly the following
way...".
∂08-Aug-89 0258 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #175
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 8 Aug 89 02:58:11 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA00783; Tue, 8 Aug 89 05:25:21 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa23540;
8 Aug 89 0:06 EDT
Date: 8 AUG 89 00:04:08 EDT
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.mc.lcs.edu>
Subject: Scheme Digest #175
To: Scheme%mc.lcs.mit.edu@mintaka.mc.lcs.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.mc.lcs.edu
Message-Id: <8908080006.aa23540@mintaka.lcs.mit.edu>
Scheme Digest #175 8 AUG 89 00:04:08 EDT
Today's Topics:
Opinions wanted.
----------------------------------------------------------------------
Date: 7 Aug 89 13:35:43 GMT
From: "Mark W. Bailey" <haven!uvaarpa!virginia!uvacs!mwb5y@purdue.edu>
Subject: Opinions wanted.
Message-Id: <MWB5Y.89Aug7093543@hopper.hopper.cs.virginia.edu>
We looking for a good book on Scheme to use in a graduate programming
languages course. I've found "The SCHEME programming language"
by Dybvig, but I don't have access to a copy. I'd like information
on this or any other books that are available.
Please send e-mail.
Mark W. Bailey mwb5y@virginia.edu
Computer Science
University of Virginia
------------------------------
End of Scheme Digest
********************
∂08-Aug-89 1701 @mc.lcs.mit.edu,@life.ai.mit.edu:shaff@sesame.stanford.edu R3.99RS issues (else)
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 8 Aug 89 17:01:40 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA06814; Tue, 8 Aug 89 19:47:24 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa00126;
8 Aug 89 11:01 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 8 Aug 89 11:01:32 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa29950;
8 Aug 89 10:56 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02346; Tue, 8 Aug 89 10:55:58 EDT
Received: from sesame.Stanford.EDU (sesame.stanford.edu) by zurich.ai.mit.edu; Tue, 8 Aug 89 10:52:36 edt
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA03048; Tue, 8 Aug 89 07:55:06 PDT
Date: Tue, 8 Aug 89 07:55:06 PDT
From: Mike Shaff <shaff@sesame.stanford.edu>
Message-Id: <8908081455.AA03048@sesame.Stanford.EDU>
To: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: will@cs.uoregon.edu's message of Mon, 7 Aug 89 17:02:53 PDT <8908080002.AA05003@spencer.cs.uoregon.edu>
Subject: R3.99RS issues (else)
ciao,
I think that Morry's argument is valid. If a user wants to use 'else' in the
cond or case special forms define the variable to be #t. This seems like a
clear example of where we can reduce the number of things the user has to
remember without screwing anyone!
I personally would like to see the language only grow with additional concepts.
(peace chance)
mas
∂08-Aug-89 1733 @mc.lcs.mit.edu,@life.ai.mit.edu:hudak-paul@yale.edu Re: sequential order of evaluation
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 8 Aug 89 17:33:45 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA07002; Tue, 8 Aug 89 20:19:17 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa00428;
8 Aug 89 11:31 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 8 Aug 89 11:32:01 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa00398;
8 Aug 89 11:29 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02577; Tue, 8 Aug 89 11:29:38 EDT
Received: from ATHENA.CS.YALE.EDU ([128.36.0.27]) by zurich.ai.mit.edu; Tue, 8 Aug 89 11:26:15 edt
Received: by ATHENA.CS.YALE.EDU; Tue, 8 Aug 89 10:07:46 EDT
From: Paul Hudak <hudak-paul@yale.edu>
Message-Id: <8908081407.AA09346@ATHENA.CS.YALE.EDU>
Received: by yale-ring (node-add2/ADD2)
via WIMP-MAIL (Version 1.3/1.5) ; Tue Aug 8 09:56:20
Date: Tue, 8 Aug 89 09:56:16 EDT
Subject: Re: sequential order of evaluation
To: will@cs.uoregon.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: will@cs.uoregon.edu, Mon, 7 Aug 89 17:01:45 PDT
The choice is explicit in the rather informal formal semantics, which says
the expressions must be evaluated sequentially in some permuted order.
To be more precise, the informal formal semantics says that whatever
permuted order is chosen must be used for ALL expressions. That bothers
me much more than having it prohibit interleaving.
How do the authors feel about adding the following note to section 4.1.3?
Note: Although the precise order of evaluation is unspecified, the
expressions must be evaluated without interleaving. Interleaving is
not allowed because Scheme provides no facilities for serializing
concurrent side effects.
Completely prohibiting interleaving seems too strong.
To kill two birds with one stone, I think the note should read something like:
Note:
(1) The unspecified order-of-evaluation may be chosen differently for
each expression.
(2) An implementation is only required to guarantee a result that is
consistent with SOME sequential order-of-evaluation (and thus
interleaving is not necessarily prohibited).
-Paul
-------
∂08-Aug-89 1910 @mc.lcs.mit.edu,@life.ai.mit.edu:mkatz@sesame.stanford.edu LIST?
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 8 Aug 89 19:09:45 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA07634; Tue, 8 Aug 89 21:57:25 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa00515;
8 Aug 89 11:37 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 8 Aug 89 11:38:19 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa00440;
8 Aug 89 11:32 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02590; Tue, 8 Aug 89 11:32:06 EDT
Received: from sesame.Stanford.EDU (sesame.stanford.edu) by zurich.ai.mit.edu; Tue, 8 Aug 89 11:28:43 edt
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA03174; Tue, 8 Aug 89 08:30:53 PDT
Date: Tue, 8 Aug 89 08:30:53 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8908081530.AA03174@sesame.Stanford.EDU>
To: will@cs.uoregon.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: will@cs.uoregon.edu's message of Mon, 7 Aug 89 17:01:02 PDT <8908080001.AA04985@spencer.cs.uoregon.edu>
Subject: LIST?
LIST? YES, YES!
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂08-Aug-89 2158 @mc.lcs.mit.edu,@life.ai.mit.edu:mkatz@sesame.stanford.edu sequential order of evaluation
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 8 Aug 89 21:58:27 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA09413; Wed, 9 Aug 89 00:48:56 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa00627;
8 Aug 89 11:44 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 8 Aug 89 11:45:10 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa00579;
8 Aug 89 11:42 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02692; Tue, 8 Aug 89 11:42:13 EDT
Received: from sesame.Stanford.EDU (sesame.stanford.edu) by zurich.ai.mit.edu; Tue, 8 Aug 89 11:38:49 edt
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA03202; Tue, 8 Aug 89 08:41:03 PDT
Date: Tue, 8 Aug 89 08:41:03 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8908081541.AA03202@sesame.Stanford.EDU>
To: will@cs.uoregon.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: will@cs.uoregon.edu's message of Mon, 7 Aug 89 17:01:45 PDT <8908080001.AA04992@spencer.cs.uoregon.edu>
Subject: sequential order of evaluation
Date: Mon, 7 Aug 89 17:01:45 PDT
From: will@cs.uoregon.edu
How do the authors feel about adding the following note to section 4.1.3?
Note: Although the precise order of evaluation is unspecified, the
expressions must be evaluated without interleaving. Interleaving is
not allowed because Scheme provides no facilities for serializing
concurrent side effects.
I find the above opaque and would like to suggest the following alternative
which uses the concept os SERIALIZABILITY as established in the database
literature.
Note: Although the precise order of evaluation is unspecified, the evaluation
of the expressions must be "serializable". An evaluation ordering is said to
be serializable if its effects are indistinguishable from those of some
sequential evaluation of the expressions. Interleaved evaluation of several
expresions is ONLY valid if the effects of interleaving are serializable (i.e.
undetectable).
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂08-Aug-89 2334 @mc.lcs.mit.edu,@ZERMATT.lcs.mit.edu:RPG@sail.stanford.edu re: sequential evaluation of arguments
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 8 Aug 89 23:34:30 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA09769; Wed, 9 Aug 89 02:24:12 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa00821;
8 Aug 89 12:02 EDT
Received: from ZERMATT.LCS.MIT.EDU (CHAOS 17316) by MC.LCS.MIT.EDU 8 Aug 89 12:03:00 EDT
Received: from SAIL.STANFORD.EDU by ZERMATT.LCS.MIT.EDU via INTERNET with SMTP id 280467; 8 Aug 89 12:02:48 EDT
Message-Id: <NJ7jX@SAIL.Stanford.EDU>
Date: 08 Aug 89 0900 PDT
From: Dick Gabriel <RPG@sail.stanford.edu>
Subject: re: sequential evaluation of arguments
To: jinx%hpesogg@sde.hp.com, ziggy@hx.lcs.mit.edu
Cc: rrrs-authors@zermatt.lcs.mit.edu
[In reply to message from jinx%hpesogg@sde.hp.com sent Tue, 8 Aug 89 00:54:21 pdt.]
Jinx writes:
Being a firm believer in Quantum Mechanics, I believe that if you
can't tell the difference, you can do anything you want. I think you
are interpreting the wording too restrictively. I interpret all such
"commands" as saying "your implementation must produce the same values
as if...", not "your implementation must act in exactly the following
way...".
Perhaps a clear statement of this should be placed at the front of the
document so that those who don't understand Quantum Mechanics can understand
Scheme.
-rpg-
∂09-Aug-89 0009 @mc.lcs.mit.edu,@life.ai.mit.edu:shaff@sesame.stanford.edu R3.99RS issues (macros in R4RS)
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 9 Aug 89 00:09:34 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA00245; Wed, 9 Aug 89 02:58:30 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa01606;
8 Aug 89 13:03 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 8 Aug 89 13:04:00 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa01536;
8 Aug 89 12:57 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA03353; Tue, 8 Aug 89 12:57:18 EDT
Received: from sesame.Stanford.EDU (sesame.stanford.edu) by zurich.ai.mit.edu; Tue, 8 Aug 89 12:53:56 edt
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA03492; Tue, 8 Aug 89 09:56:26 PDT
Date: Tue, 8 Aug 89 09:56:26 PDT
From: Mike Shaff <shaff@sesame.stanford.edu>
Message-Id: <8908081656.AA03492@sesame.Stanford.EDU>
To: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: will@cs.uoregon.edu's message of Mon, 7 Aug 89 17:02:53 PDT <8908080002.AA05003@spencer.cs.uoregon.edu>
Subject: R3.99RS issues (macros in R4RS)
ciao,
Will>The plan is for the R4RS (but not the R3.99RS) will have an appendix that
Will>describes (at least) two incompatible macro proposals and the issues that
Will>have prevented them from being resolved; this should be the only
Will>substantial difference between the R3.99RS and the R4RS.
I am in strong disagreement with the inclusion of two appendices, as the net
effect will be an unfair evaluation of the issues by the user community.
Syntactic closures without a user interface will not be 'user friendly', but I
believe addresses the issues that are important. Extend-syntax has many nice
properties, but does NOT address the issues that are important to me. I can
not believe that a compromise is not attainable by the macro committee. I
implore the committee and other interested parties to resolve this divisive
issue.
To make the point totally clear I believe that R4RS should NOT be issued until
this issue is resolved with ONE decision.
(peace chance)
mas
∂09-Aug-89 0012 @mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@ZERMATT.lcs.mit.edu:ziggy@hx.lcs.mit.edu RE: evaluation order rule
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 9 Aug 89 00:12:08 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA00276; Wed, 9 Aug 89 03:03:34 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa05380;
8 Aug 89 17:34 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 8 Aug 89 17:30:32 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa05246;
8 Aug 89 17:27 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA05808; Tue, 8 Aug 89 17:25:59 EDT
Received: from ZERMATT.LCS.MIT.EDU (zermatt.lcs.mit.edu) by zurich.ai.mit.edu; Tue, 8 Aug 89 17:22:41 edt
Received: from HX.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via INTERNET with SMTP id 280559; 8 Aug 89 17:25:18 EDT
Received: by hx.LCS.MIT.EDU (5.51/4.7); Tue, 8 Aug 89 17:23:54 EDT
Message-Id: <2827603503-1770121@RTS-8>
Sender: ziggy@rts-8.lcs.mit.edu
Date: Tue, 8 Aug 89 17:25:03 EDT
From: "Michael R. Blair" <ziggy@hx.lcs.mit.edu>
To: jinx%zurich.ai.mit.edu@zermatt.ai.mit.edu
Cc: rrrs-authors%zurich.ai.mit.edu@zermatt.ai.mit.edu
Subject: RE: evaluation order rule
As per Jinx's reply:
[paraphrase]: Breaking a rule is only illegal if someone sees you do it.
Thanks. I had hoped I was just being too literal... I get nervous when I
hear ``thou shalt not''. In this case it seems no big deal, but I worry about
restrictions that may be too strong.
Take for example the Anti-Aliasing Rule in Gifford & Lucassen's FX language:
it is intended to forbid undetected interferrence but it is worded to forbid
run-time detection&serialization of potentially interferring concurrent
threads (it forces them to signal an error instead). Thus, stating a design
desiderata as a restriction without carefully stating the principle behind it,
although expedient, can be a precarious business. [I believe the FX designers
intend to fix this deficiency in the next version of their language.]
The evaluation rule as originally stated was careful to explain the lack of
serializing facilities in Scheme as the problem but it did so as a
rationalization for forbidding non-interleaving. I had hoped that merely
adding the adjective DETECTABLE would be judicious and non-offensive.
Whatever. Guess I just don't like rules.
~Ziggy
∂09-Aug-89 0148 @mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com Re: R3.99RS issues (else)
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 9 Aug 89 01:47:44 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA00691; Wed, 9 Aug 89 04:36:08 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa07319;
8 Aug 89 20:29 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 8 Aug 89 20:29:07 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa07293;
8 Aug 89 20:24 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA07031; Tue, 8 Aug 89 20:24:17 EDT
Received: from Xerox.COM (xerox.com) by zurich.ai.mit.edu; Tue, 8 Aug 89 20:20:58 edt
Received: from Semillon.ms by ArpaGateway.ms ; 08 AUG 89 17:19:47 PDT
Date: Tue, 08 Aug 89 17:19:50 PDT
From: Pavel.pa@xerox.com
Subject: Re: R3.99RS issues (else)
In-Reply-To: <8908081455.AA03048@sesame.Stanford.EDU>
To: Mike Shaff <shaff@sesame.stanford.edu>
Cc: rrrs-authors@zurich.ai.mit.edu
Message-Id: <890808-171947-2772@Xerox>
Defining ``else'' to be #t in not sufficient to allow users to use the
``else'' keyword in case-expressions, since that position in the form is
not evaluated.
I see no reason to use #t as the ``otherwise'' clause marker in a
case-expression. It has no more semantic justification than, say, 17. The
right name for that spot is ``else''.
Pavel
∂09-Aug-89 0355 @mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com Dynamic variables
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 9 Aug 89 03:55:37 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA01177; Wed, 9 Aug 89 06:41:50 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa07634;
8 Aug 89 20:53 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 8 Aug 89 20:53:25 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa07597;
8 Aug 89 20:50 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA07222; Tue, 8 Aug 89 20:50:29 EDT
Received: from Xerox.COM (xerox.com) by zurich.ai.mit.edu; Tue, 8 Aug 89 20:47:08 edt
Received: from Semillon.ms by ArpaGateway.ms ; 08 AUG 89 17:48:10 PDT
Date: Tue, 08 Aug 89 17:48:10 PDT
From: Pavel.pa@xerox.com
Subject: Dynamic variables
To: RRRS-Authors@zurich.ai.mit.edu
Cc: Pavel.pa@xerox.com
Message-Id: <890808-174810-2879@Xerox>
This is the proposal for adding dynamic variables (aka fluid binding) to
Scheme, as approved by consensus at the first meeting of BASH. See my
message of 05 Jul 89 for the details of the motivations behind the
proposal.
We propose adding four procedures and one derived expression type to
Scheme:
(MAKE-DYNAMIC obj) [Procedure]
Create and return a new ``dynamic variable'' whose global value is obj.
(DYNAMIC-REF dvar) [Procedure]
Return the value of the given dynamic variable in the current dynamic
environment.
(DYNAMIC-SET! dvar obj) [Procedure]
Change the value of the given dynamic variable to obj in the current
dynamic environment. The returned value is unspecified.
(CALL-WITH-DYNAMIC-BINDING dvar obj thunk) [Procedure]
Invoke and return the value of the given thunk in a new, nested dynamic
environment in which the given dynamic variable has been bound to a new
location whose initial contents are the value obj. This dynamic
environment has precisely the same extent as the invocation of the thunk
and is thus captured by continuations created within that invocation and
re-established by those continuations when they are invoked.
(DYNAMIC-BIND ((var-expr val-expr) ...) . body) [Syntax]
Evaluates the var-exprs and val-exprs in an unspecified order; the
var-exprs should yield dynamic variables. Returns the result of evaluating
the body in a new, nested dynamic environment in which the given dynamic
variables have new bindings, initialized to the given values. This dynamic
environment has precisely the same extent as the evaluation of the body and
is thus captured by continuations created within the body and
re-established by those continuations on invocation.
The DYNAMIC-BIND derived expression type has the following rewrite rule:
(dynamic-bind ((<var-expr1> <val-expr1>)
(<var-expr2> <val-expr2>)
...
(<var-exprN> <val-exprN>))
. <body>)
is equivalent to
(let ((var1 <var-expr1>)
(val1 <val-expr1>)
(var2 <var-expr2>)
(val2 <val-expr2>)
...
(varN <var-exprN>)
(valN <val-exprN>)
(body-thunk (lambda () . <body>)))
(call-with-dynamic-binding var1 val1
(lambda ()
(call-with-dynamic-binding var2 val2
(lambda ()
...
(call-with-dynamic-binding varN valN
body-thunk) ... )))))
====================================================================
Some notes on this proposal:
-- I think that the ``call-with-dynamic-binding'' procedure was actually
named ``call-with-dynamic'' in the proposal passed by BASH, but that
sounded funny to me. I'm willing to change it back, though, if anyone
objects to my changing it.
-- Should there be a ``dynamic?'' predicate that is true only of dynamic
variables? I'm inclined to think so.
-- Should it be specified that dynamic variables are a new data type,
disjoint from the others? I'm again so inclined.
-- Given ``dynamic-wind'', a portable shallow-binding implementation of the
proposal can be written for all single-processor implementations of Scheme.
It was suggested at the BASH meeting that something like this be done and
placed in the library. As stated in earlier messages, multiprocessor
implementations will have to implement it more primitively; Jinx has
pointed out, however, that two simple procedures for accessing the
process-specific dynamic environment suffice.
-- This proposal does not specify whether or not
``call-with-dynamic-binding'' tail-calls the given thunk. I think this is
proper. It is possible for deep-binding implementations to use tail-call,
but only at the expense of passing the dynamic environment on every
procedure call. In shallow binding implementations, it is probably not
possible at all.
Pavel
∂09-Aug-89 0440 @mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com sequential order of evaluation
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 9 Aug 89 04:40:09 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA01352; Wed, 9 Aug 89 07:28:52 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa08015;
8 Aug 89 21:32 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 8 Aug 89 21:16:52 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa07815;
8 Aug 89 21:13 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA07317; Tue, 8 Aug 89 21:12:49 EDT
Received: from sde.hp.com (sde.hp.com) by zurich.ai.mit.edu; Tue, 8 Aug 89 21:09:30 edt
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA05770; Tue, 8 Aug 89 18:11:48 pdt
Message-Id: <8908090111.AA05770@sde.hp.com>
Received: by hpesogg; Tue, 8 Aug 89 18:11:13 pdt
Date: Tue, 8 Aug 89 18:11:13 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: hudak-paul@yale.edu
Cc: will@cs.uoregon.edu, rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Paul Hudak's message of Tue, 8 Aug 89 09:56:16 EDT <8908081407.AA09346@ATHENA.CS.YALE.EDU>
Subject: sequential order of evaluation
Reply-To: jinx%hpesogg@sde.hp.com
To kill two birds with one stone, I think the note should read something like:
Note:
(1) The unspecified order-of-evaluation may be chosen differently for
each expression.
(2) An implementation is only required to guarantee a result that is
consistent with SOME sequential order-of-evaluation (and thus
interleaving is not necessarily prohibited).
This may still be too restrictive. It seems to me that it should be
allowable to choose a different sequential order each time an
expression is evaluated, rather than choosing an order per expression.
Admittedly this will be rare because of implementation problems, but
it should not be disallowed.
∂09-Aug-89 0657 @mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com MIN and MAX (long message)
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 9 Aug 89 06:57:22 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA01948; Wed, 9 Aug 89 09:40:58 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa08093;
8 Aug 89 21:40 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 8 Aug 89 21:41:13 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa08043;
8 Aug 89 21:36 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA07396; Tue, 8 Aug 89 21:23:46 EDT
Received: from sde.hp.com (sde.hp.com) by zurich.ai.mit.edu; Tue, 8 Aug 89 21:20:23 edt
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA06014; Tue, 8 Aug 89 18:23:01 pdt
Message-Id: <8908090123.AA06014@sde.hp.com>
Received: by hpesogg; Tue, 8 Aug 89 18:22:26 pdt
Date: Tue, 8 Aug 89 18:22:26 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: will@cs.uoregon.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: will@cs.uoregon.edu's message of Mon, 7 Aug 89 16:02:42 PDT <8908072302.AA04327@spencer.cs.uoregon.edu>
Subject: MIN and MAX (long message)
Reply-To: jinx%hpesogg@sde.hp.com
Bill Rozas:
As far as I understand it (and GJS agrees with me), the example Will
shows could only be correct in an implementation where
(>= 9.999999999999998e99 #e1e100) is true. If it isn't, the
implementation of MAX/SUP is in error.
Not as I understand it. I intended for this example to illustrate
what happens in an implementation that uses IEEE 64-bit floating
point to represent inexact reals, but I goofed (because of a bug
in the least significant bit of MacScheme's implementation of
EXACT->INEXACT for large numbers). A better example is
(MAX 1.4 #e1e200) ==> 9.99999999999999969733e199
The problem with this is that
(MAX 9.99999999999999969733e199 #e1e200) ==> 9.99999999999999969733e199
while the implementation can still distinguish (in the sense of < and
>) between both arguments.
This seems wrong!
I think that requiring MAX to round up would be like requiring
(+ x y) to return a number greater than x whenever y is positive.
It sounds plausible at first, but would tend to make computations
less accurate. I have to admit, given the difficulty of coming up
with any real-world examples where MAX returns a value that is not
equal to one of its arguments, that a difference in the least
significant bit in such cases would probably be of very little
consequence, and it might make someone's mother happy.
I think your analogy is pushing it a bit. I don't expect inexact + to
follow any particular ordering properties. In fact, we know that
floating point addition (the "usual" implementation) rounds towards
even, and there are (or so I'm told) good reasons for this. I do
expect some ordering properties out of MAX/SUP, however. Otherwise I
would not be using it at all. The rule that GJS and I like, namely
that MAX/SUP should return the smallest value >= all of its arguments,
makes it more predictable than yours.
∂09-Aug-89 1545 @mc.lcs.mit.edu,@life.ai.mit.edu:bartlett@decwrl.dec.com First BASH Meeting
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 9 Aug 89 15:44:46 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA06463; Wed, 9 Aug 89 18:25:51 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa01511;
8 Aug 89 12:55 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 8 Aug 89 12:50:51 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa01371;
8 Aug 89 12:41 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02485; Tue, 8 Aug 89 11:13:44 EDT
Received: from decwrl.dec.com (decwrl.dec.com) by zurich.ai.mit.edu; Tue, 8 Aug 89 11:10:19 edt
Received: from gnomec.pa.dec.com by decwrl.dec.com (5.54.5/4.7.34)
id AA00220; Tue, 8 Aug 89 08:13:31 PDT
Received: from gnomec.pa.dec.com by decwrl.dec.com (5.54.5/4.7.34)
for rrrs-authors@zurich.ai.mit.edu; id AA00220; Tue, 8 Aug 89 08:13:31 PDT
Received: by gnomec.pa.dec.com (5.57/4.7.34)
id AA02503; Tue, 8 Aug 89 08:00:51 PDT
Date: Tue, 8 Aug 89 08:00:51 PDT
From: Joel Bartlett <bartlett@decwrl.dec.com>
Message-Id: <8908081500.AA02503@gnomec.pa.dec.com>
To: bartlett@decwrl.dec.com, rrrs-authors@zurich.ai.mit.edu
Subject: First BASH Meeting
First BASH Meeting
Bay Area Scheme Hackers (BASH) is dedicated to fostering informal
communication among those interested in the programming language Scheme in
the San Francisco Bay Area. Details to follow after we get organized.
Minutes:
The first meeting was held at Stanford on 1 August 1989 with Daniel Weise
graciously providing a place to meet and lunch. Those in attendance were:
Daniel Weise daniel@mojave.stanford.edu
Michael Shaff shaff@sesame.stanford.edu
Guillermo Rozas jinx@zurich.ai.mit.edu
Morry Katz katz@polya.stanford.edu
James O'Toole james@zermatt.lcs.mit.edu
Pierre Jouvelot jouvelot@brokaw.lcs.mit.edu
James Rauen rauen.pa@xerox.com
Pavel Curtis pavel.pa@xerox.com
Michael Plass plass.pa@xerox.com
Erik Ruf ruf@dolores.stanford.edu
Jonathan Rees jar@zurich.ai.mit.edu
Joel Bartlett bartlett@decwrl.dec.com
Following the drafting of a scribe, the first order of business was a
discussion of rrrs-authors issues.
MAX/MIN/SUP/INF
Resolved: these words may not be used in any conversation during the
meeting.
Uniform definition syntax
Pavel spoke in favor of his earlier proposal to rrrs-authors on 22 jun 89:
I'd like to request that the syntax and semantics of bodies and programs
be identical, but not quite like either one in R3RS. Let the syntax be
<program> ::= { <expression> | <definition> | (begin <program>) }*
<definition> ::= (define <variable> <expression>)
| (define (<variable> <def formals>) <body>)
<body> ::= <program>
so definitions and expressions can be freely mixed, both at ``top level''
and internally. Also, BEGINs at top level need not consist entirely of
definitions or entirely of expressions, as in R3.95RS. The semantics is
as follows:
-- (begin <program>) is entirely equivalent to <program> .
-- programs comprising only expressions and definitions have the same
meaning as given in the formal semantics in R3.95RS; that is, bindings
are established for all defined variables giving them unspecified
values after which the program is evaluated in sequence, treating
definitions as if they were assignments.
Jinx spoke in favor of the status quo, i.e. the incremental nature of top
level expression evaluation as noted in section 5.1 of R3RS.
Resolved: no resolution.
Fluid Binding
Pavel discussed his proposal for a fluid binding construct that has been
discussed on rrrs-authors. Objections were made to using the words
"fluid" or "bindings" in the name as they might conflict with existing
fluid constructs. The word "dynamic" was suggested as an alternative.
Resolved: Accept Pavel's constructs with the name changed to dynamic
variables. He will edit his proposal and resubmit to rrrs-authors.
Regularization
Morry was assigned at Snowbird to look into "regularization" of Scheme.
He made a proposal to rrrs-authors on 14 Oct 88.
Resolved: Accept his "non-controversial" recommendations.
Resolved: Accept LIST? as a new predicate. LIST? must always run to
completion, i.e. (LIST? x) => #f, where x is a circular list. Report
should note that lists are a convention, not a primitive data type. It
should also note that the property LIST? of an object may change due to
the effects of SET-CDR!.
Resolved: Without making a value judgement, it is the sense of the
meeting that this is not the time to add additional member functions.
Resolved: Additional control expressions in the style of MAP and FOR-EACH
are desirable, but the group did not muster strong support for any of the
current rrrs-authors proposals.
Resolved: No changes to APPLY.
Multiple Values
Resolved: While not everyone thinks they are a good idea, there is the
feeling that they belong in the language.
Resolved: (values 1) is equivalent to 1.
Resolved: The proposed ARITY procedure reveals too much about the
underlying implementation and should be replaced by a predicate ACCEPTS?
that tests whether a procedure will accept a given number of values. Morry
will change his proposal and resubmit to rrrs-authors.
Modules
Joel described the module system that is in Scheme->C. Scheme->C is
intended to allow Scheme code to coexist with code written in other
languages. The compiler compiles a module at a time. The source for the
module may reside in multiple files and can contain DEFINE-EXTERNAL syntax
for defining variables or procedures in other modules. A variable X that
a module wishes to make visible at the top level has the name X. All
other variables in the module are also visible at the top level with a
name of the form module-name_variable-name. It is an error for two
modules to place the same variable name at the top level.
Jinx described the MIT Scheme package system. MIT Scheme supports multiple
environments, with each package in its own environment. The package
definition is in the form of a "wiring diagram" that unifies variables
across environments. The mechanism also allows procedure integration
information and syntax extensions to be exported.
Pavel described the proposed module Scheme for Scheme Xerox. It will be
based upon Cedar's module system. Each module will have a list of imports
and exports, with an implicit import of the "scheme" interface. Imported
names cannot be assigned. Backdoor for debugging as modules may hide
items (see meta issues). When completed, the definition of the module
system will be posted to rrrs-authors (for information only, not a
proposal for RnRs).
Resolved: no proposals, no resolutions.
Macros
Jonathan reported that there is an impasse between those wanting extend
syntax and those concerned about capture problems. It is not clear how to
resolve this to produce one macro proposal.
Resolved: The macro committee should keep trying. R4RS should not go out
without a macro proposal. It should not go out with two macro proposals.
Records
Much discussion about opaque vs. non-opaque types. In order to satisfy
Jinx and other members of the non-opaque faction, a procedure that maps a
record to its record type descriptor, and some procedure that permits one
to obtain all the selectors from a record type descriptor, will be added
to the proposal.
Resolved: Pavel will update Jonathan's earlier proposal and submit to
rrrs-authors.
Meta Issue - rrrs-authors
How are decisions made? How does a concensus form? Should there be
strong leadership by the editor over the net? A general feeling of
frustration that rrrs-authors discussions don't seem to converge.
Suggestions that might make this happen were to have "someone with
sufficient moral authority" to ride herd on the net, and to require that
proposals contain more information. The example given was Common Lisp
cleanup, where each proposal had to have the problem, the solution, the
cost to users and implementers, plus pros and cons. The proposal is
revised and reissued as new issues come up.
Resolved: it would be nice if rrrs-authors worked better. It may be time
for another rrrs-authors meeting. Perhaps at POPL in San Francisco.
Meta-issue - Timing of RnRS
Proposal: R4RS should hold until there is a macro proposal. While we're
waiting, no other changes should be considered. Instead, new proposals
should be for R5RS.
Resolved: no resolution.
Meta Issue - Opaque vs. non-opaque types
Should the user of a module or record type be allowed to look inside it if
the implementer did not export such an interface? Lively discussion topic!
Resolved: no resolution.
Meta Issue - What is the purpose of the Scheme Report?
(1) To allow us to read each others code, but not constrain
anyone's implementation.
(2) To encourage the construction of common implementations to
allow the exchange of programs.
Another lively discussion topic.
Resolved: no resolution.
After spending most of the day on rrrs-authors issues. The meeting turned
to short presentations about implementations.
Scheme Xerox (Pavel Curtis, Michael Plass, James Rauen)
This implementation is intended to be the upper bound of Scheme and Cedar.
Additions include dynamic variables, macros, modules, strong typing,
concurrency, signals, and monitor locks to Scheme. Signal handling will
be done in a straight forward manner. When a signal occurs, the procedure
that is the value of the dynamic variable *handler* is called with the
signal. It may handle it, or pass it to the previous value of handler.
The project is in the design and specification stage. Implementation
expected to be under way later this year. The system will run on top of
the Portable Common Runtime (threads, garbage collection, dynamic loading,
and name management) that is being done for the port of Cedar to UNIX.
Implementation will be intercallable with Cedar. The intent is to make it
widely available.
Scheme->C (Joel Bartlett)
Scheme->C is a Scheme system designed to generate code that can be
embedded in other systems. The compiler compiles Scheme to C that is then
compiled by the system's C compiler to produce a runnable object. The
system is designed to be very portable with a minimal amount of machine
dependent code in the implementation. Besides the essentials of R3RS (and
many optionals), there are also modules, macros, foreign function calls,
and and an interface to X11's xlib. The system currently runs on VAX and
DECStation 3100 systems. For more details see Scheme Digest #47, #49, and
#63. Currently the licensing is fairly restrictive. This should change
in the near future so that it will be more generally available to
non-commercial users. When this happens, a note will be posted to the
Scheme Digest.
S48 (Jonathan Rees)
A side project to build a Scheme virtual machine. It consists of a byte
code interpreter that has a C and a Scheme implementation. The rest is
coded in Scheme. Seen as a pedagogical tool, but also as a "competitor"
to Xscheme.
Pseudoscheme (Jonathan Rees)
A Scheme to Common Lisp translator that runs in any Common Lisp system.
While it can't completely support call-with-current-continuation and tail
call, it is quite popular.
T (Jonathan Rees)
Waiting for changes from Yale. Would like to modify it so that it comes
up in an R4RS compatible environment. David Kranz has done code
generators for MIPS and SPARC processor architectures.
MIT Scheme (Jinx)
MIT Scheme is done as a tool for courses and research at MIT. While it is
available to others, MIT's needs will direct development. In the process
of shifting from an interpreter based system to a compiler based system.
Compilers are currently available for the VAX and 68020. Future work to
include faster numeric code. For more details see the recent posting to
the Scheme Digest.
The meeting concluded with a few comments on applications.
RPC
Michael Plass is going to be doing an RPC system for Scheme Xerox. It
will allow heterogeneous Scheme implementations with no shared memory to
cooperate.
Library
Jonathan Rees is the new Scheme librarian. He'd like to develop a
strategy to get more stuff into it and publicize it. He'd like to define
standard interfaces and then solicit multiple implementations, some
portable, some not. Some discussion about using Brian Reid's archive
server to handle requests for software.
Resolved: All in favor of the library.
Future BASH meetings
Resolved: We should have more. Pavel to set up a mailing list,
bash↑@xerox.com. Joel suggested that the next meeting could be at WRL
sometime in October. To be further discussed via mail. Speakers,
listeners, etc. needed.
∂10-Aug-89 0646 @mc.lcs.mit.edu,@life.ai.mit.edu:mkatz@sesame.stanford.edu R3.99RS issues (else)
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 10 Aug 89 06:46:14 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA01851; Thu, 10 Aug 89 09:36:26 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa16408;
9 Aug 89 11:42 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 9 Aug 89 11:42:57 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa16386;
9 Aug 89 11:38 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02926; Wed, 9 Aug 89 11:38:35 EDT
Received: from sesame.Stanford.EDU (sesame.stanford.edu) by zurich.ai.mit.edu; Wed, 9 Aug 89 11:35:13 edt
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA07820; Wed, 9 Aug 89 08:37:41 PDT
Date: Wed, 9 Aug 89 08:37:41 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8908091537.AA07820@sesame.Stanford.EDU>
To: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Pavel.pa@xerox.com's message of Tue, 08 Aug 89 17:19:50 PDT <890808-171947-2772@Xerox>
Subject: R3.99RS issues (else)
Date: Tue, 08 Aug 89 17:19:50 PDT
From: Pavel.pa@xerox.com
Defining ``else'' to be #t in not sufficient to allow users to use the
``else'' keyword in case-expressions, since that position in the form is
not evaluated.
As was discussed earlier in private mail, ELSE does not have to be a syntactic
keyword for its use in CASE. I advocated removing ELSE as a syntactic keyword,
which only effects COND. In my opinion, it would have been semantically
cleaner if the matching expressions in case were in an evaluated context, but
this is another issue and one which I am sure will never change for historic
reasons, if none other.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂10-Aug-89 0717 @mc.lcs.mit.edu,@life.ai.mit.edu:mkatz@sesame.stanford.edu Dynamic variables
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 10 Aug 89 07:16:44 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA02072; Thu, 10 Aug 89 10:05:23 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa16493;
9 Aug 89 11:50 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 9 Aug 89 11:50:36 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa16440;
9 Aug 89 11:45 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02979; Wed, 9 Aug 89 11:45:09 EDT
Received: from sesame.Stanford.EDU (sesame.stanford.edu) by zurich.ai.mit.edu; Wed, 9 Aug 89 11:41:37 edt
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA07848; Wed, 9 Aug 89 08:43:47 PDT
Date: Wed, 9 Aug 89 08:43:47 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8908091543.AA07848@sesame.Stanford.EDU>
To: Pavel.pa@xerox.com
Cc: RRRS-Authors@zurich.ai.mit.edu, Pavel.pa@xerox.com
In-Reply-To: Pavel.pa@xerox.com's message of Tue, 08 Aug 89 17:48:10 PDT <890808-174810-2879@Xerox>
Subject: Dynamic variables
Date: Tue, 08 Aug 89 17:48:10 PDT
From: Pavel.pa@xerox.com
This is the proposal for adding dynamic variables (aka fluid binding) to
Scheme, as approved by consensus at the first meeting of BASH. See my
message of 05 Jul 89 for the details of the motivations behind the
proposal.
This proposal was NOT accepted by consensus at BASH as I stated that I was not
comfortable with it at that meeting. Despite the fact that I have corrected
Pavel TWICE on this issue, he insists on using the word consensus in an
effort, I suppose, to give his proposal more weight. I am attempting to
formulate, in my own mind, exactly what about this proposal makes me
uncomfortable and will post a message as soon as I can make a cogent
presentation. In the meantime, however, I wanted to set the record straight.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂10-Aug-89 0725 @mc.lcs.mit.edu,@life.ai.mit.edu:jeff%aiai.edinburgh.ac.uk@nsfnet-relay.ac.uk No mail
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 10 Aug 89 07:25:50 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AB02136; Thu, 10 Aug 89 10:13:43 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa20679;
9 Aug 89 17:03 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 9 Aug 89 17:03:55 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa20636;
9 Aug 89 16:59 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA05921; Wed, 9 Aug 89 16:59:18 EDT
Received: from NSFnet-Relay.AC.UK (nsfnet-relay.ac.uk) by zurich.ai.mit.edu; Wed, 9 Aug 89 16:54:57 edt
Received: from aiai.edinburgh.ac.uk by NSFnet-Relay.AC.UK via Janet with NIFTP
id aa07324; 9 Aug 89 19:15 BST
Date: Wed, 9 Aug 89 19:21:38 BST
Message-Id: <2090.8908091821@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@nsfnet-relay.ac.uk>
Subject: No mail
To: rrrs-authors@zurich.ai.mit.edu
Cc: rrrs-authors-request <@uunet.uu.net:rrrs-authors-request@zurich.ai.mit.edu>
I have not seen any mail on this list since the end of July.
What's happened?
∂10-Aug-89 0846 ramsdell@linus.mitre.org Re: First BASH Meeting (Let's meet at POPL)
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 10 Aug 89 08:46:14 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA02664; Thu, 10 Aug 89 11:29:43 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA03748; Thu, 10 Aug 89 11:30:47 EDT
Posted-Date: Thu, 10 Aug 89 11:24:43 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA00409; Thu, 10 Aug 89 11:24:46 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8908101524.AA00409@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Cc: ramsdell@linus.mitre.org
Subject: Re: First BASH Meeting (Let's meet at POPL)
In-Reply-To: Your message of Tue, 08 Aug 89 08:00:51 -0700.
<8908081500.AA02503@gnomec.pa.dec.com>
Date: Thu, 10 Aug 89 11:24:43 EDT
>> From: Joel Bartlett <bartlett@decwrl.dec.com>
...
>> Bay Area Scheme Hackers (BASH) is dedicated to fostering informal
...
And I thought BASH was GNU's Born Again SHell....
>> Uniform definition syntax
>>
>> Pavel spoke in favor of his earlier proposal to rrrs-authors on 22 jun 89:
>>
>> Jinx spoke in favor of the status quo, i.e. the incremental nature of top
>> level expression evaluation as noted in section 5.1 of R3RS.
I am glad to see the issue get such a hearing. Thanks also to Will
for his explaination of his position. I favor dropping the issue for
consideration for R4RS.
>> Meta Issue - rrrs-authors
>>
...
>> Resolved: it would be nice if rrrs-authors worked better. It may be time
>> for another rrrs-authors meeting. Perhaps at POPL in San Francisco.
I would also like to see another rrrs-authors meeting as long as it is
not an R4RS meeting. I would like to see R4RS out before the end of
this year. R4RS should include name regularization, but if the macros
factions fail to agree, let's drop macros.
There seems to be a fair number of good solid proposals for
consideration in R5RS. Fluid variables and multiple values come
immediately to mind. Maybe we could get some agreement at POPL.
John
∂10-Aug-89 0902 @mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com R3.99RS issues (macros in R4RS)
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 10 Aug 89 08:58:49 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA02784; Thu, 10 Aug 89 11:43:17 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa20791;
9 Aug 89 17:17 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 9 Aug 89 17:16:40 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa20742;
9 Aug 89 17:10 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA06002; Wed, 9 Aug 89 17:10:48 EDT
Received: from sde.hp.com (sde.hp.com) by zurich.ai.mit.edu; Wed, 9 Aug 89 17:07:29 edt
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA04260; Wed, 9 Aug 89 14:10:30 pdt
Message-Id: <8908092110.AA04260@sde.hp.com>
Received: by hpesogg; Wed, 9 Aug 89 14:09:55 pdt
Date: Wed, 9 Aug 89 14:09:55 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: shaff@sesame.stanford.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Mike Shaff's message of Tue, 8 Aug 89 09:56:26 PDT <8908081656.AA03492@sesame.Stanford.EDU>
Subject: R3.99RS issues (macros in R4RS)
Reply-To: jinx%hpesogg@sde.hp.com
Date: Tue, 8 Aug 89 09:56:26 PDT
From: Mike Shaff <shaff@sesame.stanford.edu>
ciao,
Will>The plan is for the R4RS (but not the R3.99RS) will have an appendix that
Will>describes (at least) two incompatible macro proposals and the issues that
Will>have prevented them from being resolved; this should be the only
Will>substantial difference between the R3.99RS and the R4RS.
I am in strong disagreement with the inclusion of two appendices, as the net
effect will be an unfair evaluation of the issues by the user community.
Syntactic closures without a user interface will not be 'user friendly', but I
believe addresses the issues that are important. Extend-syntax has many nice
properties, but does NOT address the issues that are important to me. I can
not believe that a compromise is not attainable by the macro committee. I
implore the committee and other interested parties to resolve this divisive
issue.
To make the point totally clear I believe that R4RS should NOT be issued until
this issue is resolved with ONE decision.
Hear, hear!
∂10-Aug-89 1246 @mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@relay.cs.net,@tektronix.tek.com:adams@tekchips.labs.tek.com Dynamic variables
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 10 Aug 89 12:46:04 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA04123; Thu, 10 Aug 89 15:28:53 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa02141;
10 Aug 89 11:40 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 10 Aug 89 11:39:47 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa02101;
10 Aug 89 11:38 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02750; Thu, 10 Aug 89 11:38:00 EDT
Received: from RELAY.CS.NET (relay.cs.net) by zurich.ai.mit.edu; Thu, 10 Aug 89 11:34:32 edt
Received: from tektronix.tek.com by RELAY.CS.NET id aa14063; 10 Aug 89 11:37 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
id AA22625; Thu, 10 Aug 89 08:39:25 PDT
Received: by tekirl.labs.tek.com (5.51/7.1)
id AA06474; Thu, 10 Aug 89 08:35:33 PDT
Received: by tekchips.LABS.TEK.COM (5.51/6.24)
id AA11137; Thu, 10 Aug 89 08:39:47 PDT
Date: Thu, 10 Aug 89 08:39:47 PDT
From: Norman Adams <adams%tekchips.labs.tek.com@relay.cs.net>
Message-Id: <8908101539.AA11137@tekchips.LABS.TEK.COM>
To: mkatz%sesame.stanford.edu@relay.cs.net
Cc: RRRS-Authors@zurich.ai.mit.edu
In-Reply-To: Morris Katz's message of Wed, 9 Aug 89 08:43:47 PDT <8908091543.AA07848@sesame.Stanford.EDU>
Subject: Dynamic variables
I find it bothersome that something called a "variable" can be the
result of an evaluation.
-Norman
∂10-Aug-89 1332 mkatz@sesame.stanford.edu First BASH Meeting (Let's meet at POPL)
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 10 Aug 89 13:32:07 PDT
Received: from sesame.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA04678; Thu, 10 Aug 89 16:11:07 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA00461; Thu, 10 Aug 89 10:56:41 PDT
Date: Thu, 10 Aug 89 10:56:41 PDT
From: mkatz@sesame.stanford.edu (Morris Katz)
Message-Id: <8908101756.AA00461@sesame.Stanford.EDU>
To: ramsdell@linus.mitre.org
Cc: rrrs-authors@life.ai.mit.edu, ramsdell@linus.mitre.org
In-Reply-To: ramsdell@linus.mitre.org's message of Thu, 10 Aug 89 11:24:43 EDT <8908101524.AA00409@huxley.mitre.org>
Subject: First BASH Meeting (Let's meet at POPL)
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Posted-Date: Thu, 10 Aug 89 11:24:43 EDT
From: ramsdell@linus.mitre.org
Date: Thu, 10 Aug 89 11:24:43 EDT
>> From: Joel Bartlett <bartlett@decwrl.dec.com>
R4RS should include name regularization, but if the macros
factions fail to agree, let's drop macros.
Lets not drop macros. In my opinion, macros are probably the most important
addition to R3RS which justify creating an R4RS. R4RS without macros is a
quasi-worthless document. How about if we all just agree to come to a decision
on this issue. Sooner or later Scheme must have macros or die.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂10-Aug-89 1625 shaff@sesame.stanford.edu First BASH Meeting (macros)
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 10 Aug 89 16:25:44 PDT
Received: from sesame.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA07122; Thu, 10 Aug 89 19:10:35 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA00646; Thu, 10 Aug 89 13:41:35 PDT
Date: Thu, 10 Aug 89 13:41:35 PDT
From: shaff@sesame.stanford.edu (Mike Shaff)
Message-Id: <8908102041.AA00646@sesame.Stanford.EDU>
To: rrrs-authors@life.ai.mit.edu
In-Reply-To: Morris Katz's message of Thu, 10 Aug 89 10:56:41 PDT <8908101756.AA00461@sesame.Stanford.EDU>
Subject: First BASH Meeting (macros)
'Give me macros or give me death'
- Macromancer
∂12-Aug-89 0228 @mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu Re: Dynamic variables
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 12 Aug 89 02:28:22 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA00848; Sat, 12 Aug 89 05:14:22 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22338;
11 Aug 89 16:35 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 11 Aug 89 16:31:40 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa22223;
11 Aug 89 16:29 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA20174; Fri, 11 Aug 89 16:29:50 EDT
Received: from skinner.cs.uoregon.edu ([128.223.4.13]) by zurich.ai.mit.edu; Fri, 11 Aug 89 16:26:29 edt
Received: from spencer.cs.uoregon.edu by skinner.cs.uoregon.edu with SMTP
(5.59++/IDA-1.2.8) id AA05479; Fri, 11 Aug 89 12:53:55 PDT
Received: by spencer.cs.uoregon.edu; Fri, 11 Aug 89 12:53:47 PDT
Date: Fri, 11 Aug 89 12:53:47 PDT
From: will@cs.uoregon.edu
Message-Id: <8908111953.AA08745@spencer.cs.uoregon.edu>
To: Pavel.pa@xerox.com, RRRS-Authors@zurich.ai.mit.edu
Subject: Re: Dynamic variables
Pavel observed that DYNAMIC-WIND sufficed to implement a portable
shallow-binding implementation of the BASH proposal for all
single-processor implementations of Scheme, but claimed that
multiprocessor implementations will have to implement it more
primitively.
I observe that DYNAMIC-WIND suffices to implement a portable
deep-binding implementation of the BASH proposal. It seems to
me that this deep-binding implementation should work for most
multiprocessor implementations as well, provided the "right"
relationship exists between processes and continuations. Some
multiprocessor implementations might want to implement things
more primitively, either for efficiency or because their view
of what is right differs from mine.
Neither the deep-binding nor the shallow-binding implementation
in terms of DYNAMIC-WIND seems capable of supporting a tail-call
semantics for CALL-WITH-DYNAMIC-BINDING.
Peace, Will
∂12-Aug-89 1538 @mc.lcs.mit.edu,@life.ai.mit.edu:danvy@gang-of-four.stanford.edu Re: Dynamic variables
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 12 Aug 89 15:38:25 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA04664; Sat, 12 Aug 89 18:18:59 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa04565;
12 Aug 89 15:13 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 12 Aug 89 15:13:44 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa04545;
12 Aug 89 15:08 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA03649; Sat, 12 Aug 89 15:08:01 EDT
Received: from gang-of-four.Stanford.EDU (gang-of-four.stanford.edu) by zurich.ai.mit.edu; Sat, 12 Aug 89 15:04:43 edt
Received: by gang-of-four.Stanford.EDU (5.0/25-eef) id AA12068; Sat, 12 Aug 89 12:07:33 PDT
Date: Sat, 12 Aug 89 12:07:33 PDT
From: Olivier Danvy <danvy@gang-of-four.stanford.edu>
Message-Id: <8908121907.AA12068@gang-of-four.Stanford.EDU>
To: will@cs.uoregon.edu
Subject: Re: Dynamic variables
Cc: RRRS-Authors@zurich.ai.mit.edu
Will>Neither the deep-binding nor the shallow-binding implementation
Will>in terms of DYNAMIC-WIND seems capable of supporting a tail-call
Will>semantics for CALL-WITH-DYNAMIC-BINDING.
Unless, as usual, one is willing to test at such tail-calls
whether they redefine a dynamic variable, and if they do,
one does -not- save the corresponding binding since it would
be restored uselessly.
Price: more tests at runtime.
Evaluation: (1) calling and dynamically binding infinitely many
variables is not properly tail-recursive since only tail-recursive
calls that re-bind a variable can be performed properly;
(2) calling with N (N is finite) different dynamic variables
is properly tail-recursive "modulo" N.
So a "tail-call semantics" for CALL-WITH-DYNAMIC-BINDING is possible.
Most French Lisp systems actually used this technique.
Olivier
∂13-Aug-89 0537 @mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com Re: Dynamic variables
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 13 Aug 89 05:37:35 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA01697; Sun, 13 Aug 89 08:30:44 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22411;
11 Aug 89 16:42 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 11 Aug 89 16:42:47 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa22366;
11 Aug 89 16:39 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA20395; Fri, 11 Aug 89 16:39:16 EDT
Received: from Xerox.COM (xerox.com) by zurich.ai.mit.edu; Fri, 11 Aug 89 16:35:51 edt
Received: from Cabernet.ms by ArpaGateway.ms ; 11 AUG 89 13:35:43 PDT
Date: Fri, 11 Aug 89 13:37:00 PDT
From: Pavel.pa@xerox.com
Subject: Re: Dynamic variables
In-Reply-To: <8908111953.AA08745@spencer.cs.uoregon.edu>
To: will@cs.uoregon.edu
Cc: RRRS-Authors@zurich.ai.mit.edu
Message-Id: <890811-133543-9589@Xerox>
I'm afraid that I either don't see your ``right'' relationship or don't see
how to do the implementation. Could you be more explicit?
Also, if the deep binding is implemented more primitively, then you can
achieve tail-call semantics for CALL-WITH-DYNAMIC-BINDING; you simply
maintain the dynamic environment as an argument passed to every procedure.
CALL-WITH-DYNAMIC-BINDING then has an obvious implementation that
tail-calls the given thunk. I can't tell if this is in contradiction to
your final paragraph; perhaps you mean that the portable deep-binding
implementation you have in mind does not support tail-call semantics.
Pavel
∂13-Aug-89 2354 @mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com Re: Dynamic variables
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 13 Aug 89 23:54:15 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA00213; Mon, 14 Aug 89 02:44:21 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22730;
11 Aug 89 16:58 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 11 Aug 89 16:59:07 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa22562;
11 Aug 89 16:47 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA20561; Fri, 11 Aug 89 16:47:26 EDT
Received: from Xerox.COM (xerox.com) by zurich.ai.mit.edu; Fri, 11 Aug 89 16:44:00 edt
Received: from Cabernet.ms by ArpaGateway.ms ; 11 AUG 89 13:46:55 PDT
Date: Fri, 11 Aug 89 13:48:13 PDT
From: Pavel.pa@xerox.com
Subject: Re: Dynamic variables
In-Reply-To: <8908101539.AA11137@tekchips.LABS.TEK.COM>
To: Norman Adams <adams%tekchips.labs.tek.com@relay.cs.net>
Cc: RRRS-Authors@zurich.ai.mit.edu
Message-Id: <890811-134655-9610@Xerox>
I find it bothersome that something called a "variable" can be the
result of an evaluation.
In some terminologies, the procedure CONS returns a pair of two variables;
that is, the word ``variable'' is synonymous with ``location''. I don't
particularly subscribe to that point of view, however.
Perhaps ``dynamic variable'' is a misnomer. Consider the environment and
store:
env: (1) --> (2)
store (2) --> (3)
I think that it's reasonably well-established that (2) is the set of
``locations'' and (3) is the set of ``values''. In lexical environments,
(1) is usually referred to as the set of ``identifiers''. One possibility
therefore is to change the specification to say that MAKE-DYNAMIC returns a
``dynamic identifier''. This doesn't quite sound right to me, though. How
about ``dynamic names''? I guess I don't really care what these frobs are
called.
My main concerns are that shared-memory multiprocessors are not
discriminated against and that the semantics of the rest of the language
not change dramatically with the addition of dynamic binding. The BASH
proposal grew out of my only idea satisfying these two concerns.
Pavel
∂14-Aug-89 0829 @mc.lcs.mit.edu,@life.ai.mit.edu:halstead@crl.dec.com Re: Arg evaluation order
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 14 Aug 89 08:28:56 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA03007; Mon, 14 Aug 89 11:17:31 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa25164;
11 Aug 89 20:03 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 11 Aug 89 20:04:35 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa25050;
11 Aug 89 19:58 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA24767; Fri, 11 Aug 89 19:42:05 EDT
Received: from decwrl.dec.com (decwrl.dec.com) by zurich.ai.mit.edu; Fri, 11 Aug 89 19:38:43 edt
Received: from crl.crl.dec.com by decwrl.dec.com (5.54.5/4.7.34)
id AA03741; Fri, 11 Aug 89 16:41:23 PDT
Received: from crl.crl.dec.com by decwrl.dec.com (5.54.5/4.7.34)
for rrrs-authors@zurich.ai.mit.edu; id AA03741; Fri, 11 Aug 89 16:41:23 PDT
Received: by crl.crl.dec.com (5.57/Ultrix2.4-C)
id AA21422; Fri, 11 Aug 89 18:34:11 EDT
Message-Id: <8908112233.AA08043@urmel.DEC.COM>
To: andy@ads.com
Cc: rrrs-authors@zurich.ai.mit.edu, rhh@hx.lcs.mit.edu
Subject: Re: Arg evaluation order
In-Reply-To: Your message of Thu, 13 Jul 89 22:28:54 -0400.
<8907140228.AA05095@crl.crl.dec.com>
Date: Fri, 11 Aug 89 18:33:30 EDT
From: halstead@crl.dec.com
This is a response to a rather old message -- but then again, a file
system lossage recently reset my state to July 17, causing me to take
a fresh look at some then-pending mail messages (and then the first
time I tried to send this message it bounced):
> Jinx writes:
> The problem is that there are perfectly portable sequential programs
> which work when ANY sequential order is used, but not when
> interleaved. Consider, for example, ...
> Now, a compiler should be able trivially to determine that node-mark!
> is a (potential) mutator, and hence that count-nodes! is a mutator;
> thus determining that there is a race condition just in case
> (eq? (node-left graph-node) (node-right graph-node))
> is straightforward, ....
Your argument here seems to be devoted to whether a compiler can tell
that, in this case, a parallel execution could yield a result different
from that of any legal sequential execution.
I don't think anybody is trying to *prevent* a Scheme implementation
from working in parallel, if it can prove that the result of such
operation will be equivalent to that of a legal sequential execution.
The issue here is whether the Scheme specification should be weakened
so as to include as a legal execution order the kind of interleaving
that Jinx's example highlights. I agree completely with Jinx that this
would be a radical change and would cause great difficulty in writing
portable programs. You can invent a language that is like Scheme in
every respect except that it relaxes this restriction (I have, in fact),
but that's different enough that you shouldn't call it Scheme.
-Bert Halstead
∂14-Aug-89 1634 @mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu Re: Dynamic variables
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 14 Aug 89 16:34:26 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA08658; Mon, 14 Aug 89 19:22:18 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa28953;
14 Aug 89 19:19 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 14 Aug 89 19:19:07 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa28929;
14 Aug 89 19:15 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA08586; Mon, 14 Aug 89 19:15:08 EDT
Received: from oregon.uoregon.edu (oregon.uoregon.edu) by zurich.ai.mit.edu; Mon, 14 Aug 89 19:11:40 edt
Received: from spencer.cs.uoregon.edu by oregon.uoregon.edu; Mon, 14 Aug 89
16:13 PDT
Received: by spencer.cs.uoregon.edu; Mon, 14 Aug 89 16:14:27 PDT
Date: Mon, 14 Aug 89 16:14:27 PDT
From: will@cs.uoregon.edu
Subject: Re: Dynamic variables
To: Pavel.pa@xerox.com
Cc: RRRS-Authors@zurich.ai.mit.edu
Message-Id: <8908142314.AA27913@spencer.cs.uoregon.edu>
I'm afraid that I either don't see your ``right'' relationship or don't see
how to do the implementation. Could you be more explicit?
No. I goofed. Sorry about that.
Peace, Will
∂15-Aug-89 1812 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #177
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 15 Aug 89 18:12:26 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA10069; Tue, 15 Aug 89 20:28:39 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa26313;
10 Aug 89 1:02 EDT
Date: 10 AUG 89 00:06:51 EDT
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.mc.lcs.edu>
Subject: Scheme Digest #177
To: Scheme%mc.lcs.mit.edu@mintaka.mc.lcs.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.mc.lcs.edu
Message-Id: <8908100102.aa26313@mintaka.lcs.mit.edu>
Scheme Digest #177 10 AUG 89 00:06:51 EDT
Today's Topics:
"Scheme has data types and Lisp doesn't."
functional command shells?
----------------------------------------------------------------------
Date: 9 Aug 89 16:00:44 GMT
From: Dan Weinreb <odi!valens!dlw@uunet.uu.net>
Subject: Re: "Scheme has data types and Lisp doesn't."
Message-Id: <410@odi.ODI.COM>
In article <13046@well.UUCP> nagle@well.UUCP (John Nagle) writes:
This is very confused. It's hard to know where to begin.
It's more of an MIT vs the rest of the LISP world tradition.
If you are contrasting Lisp and Scheme, it's hard to see how this can
be a conflict between MIT and the rest of the Lisp world. Scheme is
from MIT. Traditionally, the Lisps with the best numeric support,
compared to other Lisps, are *also* from MIT (particularly the NCOMPLR
for Maclisp).
Although Common LISP has data type declarations of a sort, they tend
not to be taken all that seriously by compilers.
This is not the case. Many major Lisp compilers for standard
hardware, such as Lucid and Franz, pay close attention to numeric
declarations, and produce far better numeric code when the
declarations are present.
CLTL is very weak
on this subject:
Yes; this is intentional. The idea is to accomodate both standard
hardware, for which the declarations are needed, and Lisp machines,
for which they are superfluous.
There's a faction in the LISP world that feels that
floating point is unimportant. The strongest expression of this feeling
was in the early Symbolics machines, which lacked floating point hardware.
What? The reason that the Symbolics LM-2 lacked floating point
hardware had nothing to do with a "strong expression of a feeling"; it
was due to marketing timing and economics. The LM-2 was just a
repackaged MIT prototype, and the idea was to get it shipped as fast
as possible, reserving improvements for later hardware platforms.
Machines that were actually designed by Symbolics all had floating
point accelerators, generally based on Weitek floating point chips.
Symbolics typically did very well in Lisp floating point benchmarks.
Furthermore, I know of no "faction" anywhere in the Lisp world that
claims that floating point is unimportant.
Much of the weakness on typing in Common Lisp reflects lobbying from the
Symbolics faction, which generally supported the idea that everything
possible should be dynamic.
That the language should not REQUIRE declarations. And it didn't
require any lobbying; the conventional-hardware faction agreed with
the philosophy that declarations should be optional hints from the
user to the compiler. Guy Steele, Richard Gabriel, and Scott Fahlman
never have advocated mandatory declarations of the types of variables
in Lisp. There was plenty of lobbying during the design of Common Lisp,
but not about this point.
Reading section 4.5 of CLTL (Common Lisp, the Language) will give
you a good feeling of the weakness of the commitment to strong typing
in Common Lisp.
You bet. There is no committment to "strong typing" (typed variables)
in Common Lisp. This is very much intentional.
What people tend to actually implement are systems in which all objects
are "LISP objects", and are still individually allocated and pointed to.
Yes, in the general case.
Defining an array of "short-float" is likely to generate an array of pointers
to LISP objects.
Nope. Not on Symbolics machines and not on the conventional-machine
implementations that I'm aware of. Lisp objects are not always
implemented as pointers; they can be stored "immediately". The
technique of doing this for numbers is nicknamed "inums" and has been
around for at least 15 years.
And none of this has anything to do with the original query, since
Lisp and Scheme are essentially the same in these regards. Scheme
doesn't have typed variables, either.
------------------------------
Date: 10 Aug 89 00:05:06 GMT
From: "Peter R. Ham" <shelby!polya!Polya.Stanford.EDU!ham@decwrl.dec.com>
Subject: functional command shells?
Message-Id: <HAM.89Aug9170506@Polya.Stanford.EDU>
Are any of these shells, like fsh, available?
--
Peter Ham PO Box 3430 (h)(415) 324-9645
MS Computer Science Student Stanford, CA ham@polya.stanford.edu
Stanford University 94309 (o)(415) 723-2067
------------------------------
End of Scheme Digest
********************
∂20-Aug-89 1056 @mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com Programmer-defined data types
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 20 Aug 89 10:55:58 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA03709; Sun, 20 Aug 89 13:37:59 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa05421;
18 Aug 89 21:38 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 18 Aug 89 21:38:47 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa05374;
18 Aug 89 21:35 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA10884; Fri, 18 Aug 89 21:34:46 EDT
Received: from Xerox.COM (xerox.com) by zurich.ai.mit.edu; Fri, 18 Aug 89 21:31:16 edt
Received: from Cabernet.ms by ArpaGateway.ms ; 18 AUG 89 18:34:07 PDT
Date: Fri, 18 Aug 89 18:36:26 PDT
From: Pavel.pa@xerox.com
Subject: Programmer-defined data types
To: RRRS-Authors@zurich.ai.mit.edu
Cc: Pavel.pa@xerox.com
Message-Id: <890818-183407-4872@Xerox>
This is the proposal for adding records (aka programmer-defined data types,
aka opaque types) to Scheme, as approved by consensus at the first meeting
of BASH. It is derived from discussion at that meeting and messages to
RRRS-Authors on 8 Jul 87 and 26 May through 7 Jun 88.
I apologize in advance for the verbosity of the description; no good
precision-preserving abbreviations occurred to me as I was writing it up.
We propose adding the following procedures to Scheme:
(MAKE-RECORD-TYPE type-name slot-names)
Returns a ``record-type descriptor'', a value representing a new data type,
disjoint from all others. The type-name argument must be a string, but is
only used for debugging purposes (such as the printed representation of a
record of the new type). The slot-names argument is a list of symbols
naming the ``slots'' of a record of the new type. It is an error if the
list contains any duplicates.
(RECORD-CONSTRUCTOR rtd)
Returns a procedure for constructing new members of the type represented by
rtd. The returned procedure accepts exactly as many arguments as there
were slot-names in the call to MAKE-RECORD-TYPE that created the type
represented by rtd; these are used, in order, as the initial values of
those slots in a new record, which is returned by the constructor
procedure.
(RECORD-PREDICATE rtd)
Returns a procedure for testing membership in the type represented by rtd.
The returned procedure accepts exactly one argument and returns a true
value if the argument is a member of the indicated record type; it returns
a false value otherwise.
(RECORD-ACCESSOR rtd slot-name)
Returns a procedure for reading the value of a particular slot of a member
of the type represented by rtd. The returned procedure accepts exactly one
argument which must be a record of the appropriate type; it returns the
current value of the slot named by the symbol slot-name in that record.
The symbol slot-name must be a member of the list of slot-names in the call
to MAKE-RECORD-TYPE that created the type represented by rtd.
(RECORD-UPDATER rtd slot-name)
Returns a procedure for writing the value of a particular slot of a member
of the type represented by rtd. The returned procedure accepts exactly two
arguments: a record of the appropriate type and an arbitrary Scheme value;
it modifies the slot named by the symbol slot-name in that record to
contain the given value. The returned value of the updater procedure is
unspecified. The symbol slot-name must be a member of the list of
slot-names in the call to MAKE-RECORD-TYPE that created the type
represented by rtd.
(RECORD? obj)
Returns a true value if obj is a record of any type and a false value
otherwise.
(RECORD-TYPE-DESCRIPTOR record)
Returns a record-type descriptor representing the type of the given record.
That is, for example, if the returned descriptor were passed to
RECORD-PREDICATE, the resulting predicate would return a true value when
passed the given record. Note that it is not necessarily the case that the
returned descriptor is the one that was passed to RECORD-CONSTRUCTOR in the
call that created the constructor procedure that created the given record.
(RECORD-TYPE-NAME rtd)
Returns the type-name associated with the type represented by rtd. The
returned value is EQV? to the type-name argument given in the call to
MAKE-RECORD-TYPE that created the type represented by rtd.
(RECORD-TYPE-SLOT-NAMES rtd)
Returns a list of the symbols naming the slots in members of the type
represented by rtd. The returned value is EQUAL? to the slot-names
argument given in the call to MAKE-RECORD-TYPE that created the type
represented by rtd.
=====================
Notes on the proposal
=====================
[Some of the notes below are taken from the discussion in 1988.]
-- The only significant difference between this proposal and the one made
by Jonathan Rees in his message of 26 May 88 is the inclusion of procedures
to ``inspect'' records. These procedures were referred to as
``abstraction-breaking'' in Jonathan's proposal.
-- The procedure RECORD? is necessary to allow reliable use of the
procedure RECORD-TYPE-DESCRIPTOR.
-- The type-name argument to MAKE-RECORD-TYPE is constrained to be a string
in order to allow experimentation with interesting semantics for other
kinds of values there. One possibility raised in the discussion in 1988
was some kind of a ``handler'' procedure, as in T objects.
-- We do not propose any general macro for the definition of record types.
The feeling is that this is not easy to do in a way that is both elegant
and sufficiently flexible. Once we have macros, the primitives above
should be sufficient for portable experimentation.
-- Should there be a RECORD-COPIER procedure? Some folks would like to
have one for performance and convenience; others point out that a copier
for any particular type is easy to write. In fact, given the inspection
primitives above, one can even write a somewhat slow but general record
copying procedure that works on all types.
-- The issues of subtyping and inheritance, print methods, and integration
with modules and/or
environments (e.g. Pascal's WITH construct) have been purposely avoided in
order to achieve more rapid consensus. Designs for adding single
inheritance appeared in the discussion in 1988.
-- A case can be made that constructor procedures should take no arguments
and leave all slots in new records uninitialized. There appear to be
advantages to both points of view.
-- It is probably easy to agree on how EQ? and EQV? treat records; they
should be treated in the same way as pairs, vectors, and strings. The
consensus of those I've spoken to concerning EQUAL? is that it should be
equivalent to EQV? on records, instead of treating them as it treats
vectors, pairs, and strings. I have no opinion on the subject and look
forward to hearing any alternative points of view.
Pavel
∂21-Aug-89 1359 ramsdell@linus.mitre.org Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Aug 89 13:59:11 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA04683; Mon, 21 Aug 89 16:40:08 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA07583; Mon, 21 Aug 89 08:15:41 EDT
Posted-Date: Mon, 21 Aug 89 08:15:36 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA07557; Mon, 21 Aug 89 08:15:38 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8908211215.AA07557@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Cc: ramsdell@linus.mitre.org
Subject: Multiple values for R4RS.
Date: Mon, 21 Aug 89 08:15:36 EDT
Maybe there is enough consensus to allow agreement on the
non-controversial aspects of multiple values for R4RS. What do people
think about adding only VALUES and APPLY-VALUES?
-----------------Adapted from Mike Shaff <shaff@sesame.stanford.edu>.
(values obj ...) essential procedure
Returns 0 or more values to a receiving procedure (See apply-values).
(values) => returns zero (no) values
(values 1) => returns a single value, 1
(values 1 'a) => returns two values, 1 and the symbol a
(apply-values receiver generator) essential procedure
Returns the result of applying the procedure 'receiver' to the values
produced by calling procedure 'generator' with no arguments. It is an
error if 'receiver' cannot be applied to the number of values returned
by 'generator' or if 'generator' cannot be called with zero arguments.
(apply-values cons
(lambda ()
(values 1 2))) => (1 . 2)
--------------------------------
Note: I think a useful extension of apply-values is
(apply-values receiver generator . generator-args)
Returns the result of applying the procedure 'receiver' to the values
produced by calling procedure 'generator' with 'generator-args'. It
is an error if 'receiver' cannot be applied to the number of values
returned by 'generator' or if 'generator' cannot be called with the
number of values in 'generator-args'.
John
∂21-Aug-89 1450 cph@zurich.ai.mit.edu Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Aug 89 14:50:32 PDT
Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA05287; Mon, 21 Aug 89 17:37:04 EDT
Received: from localhost by zurich.ai.mit.edu; Mon, 21 Aug 89 17:33:49 edt
Date: Mon, 21 Aug 89 17:33:49 edt
From: cph@zurich.ai.mit.edu (Chris Hanson)
Message-Id: <8908212133.AA24382@zurich.ai.mit.edu>
To: ramsdell@linus.mitre.org
Cc: rrrs-authors@life.ai.mit.edu
In-Reply-To: ramsdell@linus.mitre.org's message of Mon, 21 Aug 89 08:15:36 EDT <8908211215.AA07557@huxley.mitre.org>
Subject: Multiple values for R4RS.
From: ramsdell@linus.mitre.org
Date: Mon, 21 Aug 89 08:15:36 EDT
Maybe there is enough consensus to allow agreement on the
non-controversial aspects of multiple values for R4RS. What do people
think about adding only VALUES and APPLY-VALUES?
I'm not sure how this circumvents the "controversial" aspects. As I
understood it, the controversy had to do with the semantics of how
VALUES interacted with the continuation in effect where it was called.
[...]
(apply-values receiver generator)
I've been using a similar interface for multiple values for about a
year now, the major difference being that instead of `apply-values'
there is an operation `with-values' which has these two arguments in
the opposite order. I think the order of arguments is somewhat
important: `with-values' orders the generator and receiver so that
they are executed in the same order in which they appear
(left-to-right), while `apply-values' executes them in the opposite
order. I think `with-values' is significantly easier to read; I'd
favor having the arguments appear in that order, even though it screws
up the "generator arguments" extension (sorry, I don't find that
extension very interesting). This is (at least part of) the same
reasoning that makes `let' easier to read than its `lambda' expansion.
∂21-Aug-89 1539 harris%hplwhh@hplabs.hp.com Re: Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Aug 89 15:39:28 PDT
Received: from hplms2.hpl.hp.com by life.ai.mit.edu (4.1/AI-4.10) id AA05826; Mon, 21 Aug 89 18:24:52 EDT
Received: from hplwhh.HPL.HP.COM (hplwhh.hpl.hp.com) by hplms2.hp.com; Mon, 21 Aug 89 14:26:10 pdt
Received: from localhost by hplwhh.HPL.HP.COM; Mon, 21 Aug 89 15:23:37 pdt
Message-Id: <8908212223.AA14032@hplwhh.HPL.HP.COM>
To: ramsdell@linus.mitre.org
Cc: rrrs-authors@life.ai.mit.edu
Subject: Re: Multiple values for R4RS.
In-Reply-To: Your message of "Mon, 21 Aug 89 08:15:36 EDT."
<8908211215.AA07557@huxley.mitre.org>
Date: Mon, 21 Aug 89 15:23:33 PDT
From: Warren Harris <harris%hplwhh@hplabs.hp.com>
Your proposal doesn't say what happens when the number of values
expected by the receiver is different from the number the generator
produces. A simple case is when multiple values are returned and one
is expected:
(cons (values 1 2) 3)
=> (1 . 3)
=> (<?> . 3)
=> <error>
In the case of most functions (like CONS), I favor signaling an error,
but I can imagine some cases where passing multiple values as a single
parameter into a function should be permitted.
My argument stems from my discontent with Common Lisp when I have to
write code like:
(let ((a (foo)))
(multiple-value-bind (b c d)
(bar)
(let ((e (baz)))
...)))
when I would much prefer to write:
(let* ((a (foo))
((b c d) (bar))
(e (baz)))
...)
Granted, this can be accomplished by extending the syntax of LET*,
which in Scheme would expand to:
(let ((a (foo)))
(apply-values
(lambda (b c d)
(let ((e (baz)))
...))
(bar)))
but the same is not true of LET:
(let ((a (foo))
((b c d) (bar))
(e (baz)))
...)
-->
((lambda (a (b c d) e)
...)
(foo)
(bar)
(baz))
This suggests an extension of LAMBDA in which it may be specified that
multiple values can be passed in by a single parameter. In addition
to the conciseness this permits with LET and LET*, one could also
imagine writing code with this extended LAMBDA such as:
(define foo
(lambda (a (b c))
(list a b c)))
(foo 1 (values 2 3))
=> (1 2 3)
(foo 1 2)
=> <error>
---PROPOSAL---------------------------------------------------------------------
(LAMBDA <formals> <body>) essential syntax
<formals> ::= <variable>
| (<var/values>*)
| (<var/values>+ . <variable>)
<var/values> ::= <variable> ; single value
| (<var/values>*) ; multiple values
(LET (<binding spec>*) <body>) essential syntax
(LET* (<binding spec>*) <body>) essential syntax
<binding spec> ::= (<var/values> <expression>)
(VALUES . <expression>*) essential procedure
(APPLY-VALUES <receiver> <generator>) essential procedure
- with appropriate error messages when numbers of values mismatch.
- also suggest renaming APPLY to APPLY-LIST.
--------------------------------------------------------------------------------
Note that:
(apply-values (lambda (a b c) ...) (foo))
is equivalent to:
((lambda ((a b c)) ...) (foo))
I realize that the cost to implementors is much higher for this
proposal, but I think the power and conciseness of expression
justifies it.
Warren Harris
∂21-Aug-89 1543 @mc.lcs.mit.edu,@gateway.think.com:gls@think.com Numbers
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Aug 89 15:43:31 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA05856; Mon, 21 Aug 89 18:28:47 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa09616;
21 Aug 89 11:39 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Aug 89 11:39:08 EDT
Received: from Gateway.Think.COM by mintaka.lcs.mit.edu id aa09594;
21 Aug 89 11:36 EDT
Received: from fafnir.think.com by Think.COM; Mon, 21 Aug 89 11:37:17 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Mon, 21 Aug 89 11:34:48 EDT
Received: by verdi.think.com; Mon, 21 Aug 89 11:34:37 EDT
Date: Mon, 21 Aug 89 11:34:37 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8908211534.AA29201@verdi.think.com>
To: Alan@reagan.ai.mit.edu
Cc: gls@think.com, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Alan Bawden's message of Thu, 27 Jul 89 21:15 EDT <19890728011525.2.ALAN@PIGPEN.AI.MIT.EDU>
Subject: Numbers
I'm back from an exhausting, and therefore very restful, vacation.
Back into the fray!
Date: Thu, 27 Jul 89 21:15 EDT
From: Alan Bawden <Alan@reagan.ai.mit.edu>
I wonder, by the way, what those of you who insist that MAX must return
something EQV? to one of its arguments because "MAX computes -the- maximum
of a set of numbers", think should be the answer in the case of (MAX 1 1.0)?
Either 1 or 1.0. By the same token I believe the result of (MAX 1 1)
may be either occurrence of "1" (by stating it this way I avoid
commmitment on the question of whether the two occurrences of "1" are
the same or not).
Here is a new proposal. Given a set of points within a partial order,
there are two interesting kinds of "max"-like operation. One is to find
some point (not necessarily within the set) that is >= all points in the
given set; this is SUP. In a general poset there may be many such points;
the lattice property guarantees uniqueness.
Another is to find some point in the set such that no point in the set is >
that point. This can fail for infinite sets, but that cannot occur in
Scheme. It may also be that there is more than one such point in the set.
In that case we must define some tie-breaking rule (arbitrary choice is one
such rule). One partial tie-breaking rule that I find appealing is to
choose one of the least exact of otherwise qualified candidates. I had
earlier proposed to call this second operation MAX.
The new proposal is the call the first kind SUP (as before), and to
call the second kind LARGEST (similarly INF and SMALLEST). Let Scheme
have no built-in operations called MIN and MAX.
I still believe both kinds of operation are useful. They reflect two
different points of view about inexact numbers. One is that they are
shadows of Platonically ideal real numbers, pitifully striving to mirror
the behavior of their exact counterparts and to retain some record of the
degree of their failure. The other is that they are objects unto
themselves, obeying perfectly an algebraic system that is useful because it
is similar, though not identical, to that for real numbers and much easier
to implement.
Theologically or politically speaking, under the first view inexact numbers
strive to obey laws acknowledged to be perfect, but to a greater or lesser
degree are each in a state of sin. Under the second view they are all
model citizens, adhering perfectly to their own laws which, however, are
acknowledged not to be ideal but merely the best one can do in this
imperfect and finite world.
--Guy
∂21-Aug-89 1652 jinx@hpesogg.hp.com Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Aug 89 16:52:26 PDT
Received: from sde.hp.com (hp-sde.sde.hp.com) by life.ai.mit.edu (4.1/AI-4.10) id AA06523; Mon, 21 Aug 89 19:38:03 EDT
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA24643; Mon, 21 Aug 89 16:37:52 pdt
Message-Id: <8908212337.AA24643@sde.hp.com>
Received: by hpesogg; Mon, 21 Aug 89 16:37:12 pdt
Date: Mon, 21 Aug 89 16:37:12 pdt
From: Guillermo J. Rozas <jinx@hpesogg.hp.com>
To: ramsdell@linus.mitre.org
Cc: rrrs-authors@life.ai.mit.edu, ramsdell@linus.mitre.org
In-Reply-To: ramsdell@linus.mitre.org's message of Mon, 21 Aug 89 08:15:36 EDT <8908211215.AA07557@huxley.mitre.org>
Subject: Multiple values for R4RS.
Reply-To: jinx%hpesogg@sde.hp.com
Maybe there is enough consensus to allow agreement on the
non-controversial aspects of multiple values for R4RS. What do people
think about adding only VALUES and APPLY-VALUES?
I don't think they are worth adding if ACCEPTS? is not included as
well. ACCEPTS? allows a programmer to extend old operations into new
ones which match their continuation. For example, QUOTIENT can be
cleanly upgraded to return two values when expected, but its old
single value when only one is expected.
The reason Mike and Morry added ACCEPTS? to the proposal is that I
did not consider it interesting without some way of providing the
functionality that I want.
Without ACCEPTS?, their use and functionality can be provided in user
code, although without the error checking or the efficiency of a
"native" implementation.
∂22-Aug-89 0445 ramsdell@linus.mitre.org Re: Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89 04:44:57 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA02147; Tue, 22 Aug 89 07:21:23 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA28804; Tue, 22 Aug 89 07:16:10 EDT
Posted-Date: Tue, 22 Aug 89 07:16:05 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA08527; Tue, 22 Aug 89 07:16:07 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8908221116.AA08527@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Cc: ramsdell@linus.mitre.org
Subject: Re: Multiple values for R4RS.
In-Reply-To: Your message of Mon, 21 Aug 89 17:33:49 -0400.
<8908212133.AA24382@zurich.ai.mit.edu>
Date: Tue, 22 Aug 89 07:16:05 EDT
>> I'm not sure how this circumvents the "controversial" aspects. As I
>> understood it, the controversy had to do with the semantics of how
>> VALUES interacted with the continuation in effect where it was called.
Given Shaff's proposal, I thought the controversy was just over
ACCEPTS?. I thought the "obvious" semantics implied by the
denotational semantics had finally been accepted. Maybe I am wrong.
>>
>> [...]
>>
>> (apply-values receiver generator)
>>
>> I've been using a similar interface for multiple values for about a
>> year now, the major difference being that instead of `apply-values'
>> there is an operation `with-values' which has these two arguments in
>> the opposite order.
I too prefer the arguments in reverse order so that the most straight
forward extension of apply-values is to make a CPS style call.
(apply-value generator receiver . generator-args)
or using other names
(apply-values procedure continuation . procedure-args)
[continuation here means a procedure representing a continuation].
I thought the order of arguments is not important enought to stand in
the way of agreement. Maybe I am wrong.
>> From: Warren Harris <harris%hplwhh@hplabs.hp.com>
>>
>> Your proposal doesn't say what happens when the number of values
>> expected by the receiver is different from the number the generator
>> produces.
Sure it does. It clearly states "it is an error if 'receiver' cannot
be applied to the number of values returned by 'generator' or if
'generator' cannot be called with zero arguments". Warren, please
reread my proposal.
>> From: Guillermo J. Rozas <jinx@hpesogg.hp.com>
>>
>> I don't think they are worth adding if ACCEPTS? is not included as
>> well.
....
>> Without ACCEPTS?, their use and functionality can be provided in user
>> code, although without the error checking or the efficiency of a
>> "native" implementation.
The point is that by adding just VALUES and APPLY-VALUES, programmers
can depend on the efficiency and error checking of a "native"
implementation.
John
---- Amended multiple values proposal.
(values obj ...) essential procedure
Returns 0 or more values to a receiving procedure (See apply-values).
(values) => returns zero (no) values
(values 1) => returns a single value, 1
(values 1 'a) => returns two values, 1 and the symbol a
(apply-values generator receiver) essential procedure
Returns the result of applying the procedure 'receiver' to the values
produced by calling procedure 'generator' with no arguments. It is an
error if 'receiver' cannot be applied to the number of values returned
by 'generator' or if 'generator' cannot be called with zero arguments.
(apply-values
(lambda ()
(values 1 2))
cons) => (1 . 2)
--------------------------------
∂22-Aug-89 1052 harris%hplwhh@hplabs.hp.com Re: Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89 10:52:34 PDT
Received: from hplms2.hpl.hp.com by life.ai.mit.edu (4.1/AI-4.10) id AA01885; Tue, 22 Aug 89 13:35:01 EDT
Received: from hplwhh.HPL.HP.COM (hplwhh.hpl.hp.com) by hplms2.hp.com; Tue, 22 Aug 89 09:38:41 pdt
Received: from localhost by hplwhh.HPL.HP.COM; Tue, 22 Aug 89 09:38:26 pdt
Message-Id: <8908221638.AA14520@hplwhh.HPL.HP.COM>
To: ramsdell@linus.mitre.org
Cc: rrrs-authors@life.ai.mit.edu
Subject: Re: Multiple values for R4RS.
In-Reply-To: Your message of "Tue, 22 Aug 89 07:16:05 EDT."
<8908221116.AA08527@huxley.mitre.org>
Date: Tue, 22 Aug 89 09:38:22 PDT
From: Warren Harris <harris%hplwhh@hplabs.hp.com>
My apologies. Your proposal certainly does talk about number of
values mismatching. I guess I got excited about this extended lambda
idea.
∂22-Aug-89 1130 ramsdell@linus.mitre.org Re: Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89 11:30:05 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA02350; Tue, 22 Aug 89 14:05:24 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA02873; Tue, 22 Aug 89 14:00:12 EDT
Posted-Date: Tue, 22 Aug 89 14:00:07 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA08733; Tue, 22 Aug 89 14:00:09 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8908221800.AA08733@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Cc: ramsdell@linus.mitre.org
Subject: Re: Multiple values for R4RS.
In-Reply-To: Your message of Tue, 22 Aug 89 09:43:26 -0700.
<8908221643.AA01234@sesame.Stanford.EDU>
Date: Tue, 22 Aug 89 14:00:07 EDT
I cannot figure out what some of you would like me to conclude from
your responses. My premise is that VALUES and APPLY-VALUES as defined
reflect existing practice in some Scheme dialects, are useful, and are
non-controversial enough to add to R4RS. Let me suggest some
questions to answer which may help clear up my confusion.
[1] Do you think VALUES and APPLY-VALUES as defined are controversial?
(I understand CPH's view on this issue).
[2] Do you think VALUES and APPLY-VALUES as defined reflect existing
practice? For example, in T, VALUES = RETURN, and APPLY-VALUES =
(LAMBDA (X Y) (RECEIVE-VALUES Y X)), and MIT Scheme has the
functionality.
[3] Do you think VALUES and APPLY-VALUES as defined prohibit the
future inclusion of ACCEPTS? or some other proposal to deal with
incompatiable arities?
[4] Do you believe VALUES and APPLY-VALUES should be excluded from
Scheme solely because there is no agreement on how to deal with
incompatiable arities?
John
---- Amended multiple values proposal.
(values obj ...) essential procedure
Returns 0 or more values to a receiving procedure (See apply-values).
(values) => returns zero (no) values
(values 1) => returns a single value, 1
(values 1 'a) => returns two values, 1 and the symbol a
(apply-values generator receiver) essential procedure
Returns the result of applying the procedure 'receiver' to the values
produced by calling procedure 'generator' with no arguments. It is an
error if 'receiver' cannot be applied to the number of values returned
by 'generator' or if 'generator' cannot be called with zero arguments.
(apply-values
(lambda ()
(values 1 2))
cons) => (1 . 2)
--------------------------------
∂22-Aug-89 1150 mkatz@sesame.stanford.edu Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89 11:50:13 PDT
Received: from sesame.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA02587; Tue, 22 Aug 89 14:25:33 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA01234; Tue, 22 Aug 89 09:43:26 PDT
Date: Tue, 22 Aug 89 09:43:26 PDT
From: mkatz@sesame.stanford.edu (Morris Katz)
Message-Id: <8908221643.AA01234@sesame.Stanford.EDU>
To: ramsdell@linus.mitre.org
Cc: rrrs-authors@life.ai.mit.edu, ramsdell@linus.mitre.org
In-Reply-To: ramsdell@linus.mitre.org's message of Mon, 21 Aug 89 08:15:36 EDT <8908211215.AA07557@huxley.mitre.org>
Subject: Multiple values for R4RS.
∂22-Aug-89 1221 dyb@iuvax.cs.indiana.edu Re: Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89 12:21:00 PDT
Received: from iuvax.cs.indiana.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02931; Tue, 22 Aug 89 14:51:14 EDT
Message-Id: <8908221851.AA02931@life.ai.mit.edu>
Received: by iuvax.cs.indiana.edu
Date: Tue, 22 Aug 89 13:51:43 -0500
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
To: jinx%hpesogg@sde.hp.com
Subject: Re: Multiple values for R4RS.
Cc: rrrs-authors@life.ai.mit.edu
Let me take a stab at "quotient-and-maybe-remainder":
(define quotient-and-maybe-remainder
(lambda (n1 n2)
(call/cc
(lambda (k)
(if (accepts? k 2)
(let ([q (quotient n1 n2)])
(let ([r (- n1 (* q n2))])
(k q r)))
(k (quotient n1 n2)))))))
Unless I'm missing something and there is a different way to do this, I
guess I'm not too excited about "accepts?".
The predicate "accepts?" seems a little like the (rejected) predicate
"continuation?". A procedure may not complain "up front" about a given
number of arguments, but may complain at some later time. Or it may
accept any number of arguments, but ignore all but the first few. I
don't see how "accepts?" can be generally useful if it breaks down in
these cases.
(define kons
(lambda l
(apply cons l)))
(accepts? cons 3) => #f
(accepts? kons 3) => #t
Kent
∂22-Aug-89 1234 mkatz@sesame.stanford.edu Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89 12:32:52 PDT
Received: from sesame.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA03066; Tue, 22 Aug 89 15:08:15 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA01234; Tue, 22 Aug 89 09:43:26 PDT
Date: Tue, 22 Aug 89 09:43:26 PDT
From: mkatz@sesame.stanford.edu (Morris Katz)
Message-Id: <8908221643.AA01234@sesame.Stanford.EDU>
To: ramsdell@linus.mitre.org
Cc: rrrs-authors@life.ai.mit.edu, ramsdell@linus.mitre.org
In-Reply-To: ramsdell@linus.mitre.org's message of Mon, 21 Aug 89 08:15:36 EDT <8908211215.AA07557@huxley.mitre.org>
Subject: Multiple values for R4RS.
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Posted-Date: Mon, 21 Aug 89 08:15:36 EDT
From: ramsdell@linus.mitre.org
Date: Mon, 21 Aug 89 08:15:36 EDT
Maybe there is enough consensus to allow agreement on the
non-controversial aspects of multiple values for R4RS. What do people
think about adding only VALUES and APPLY-VALUES?
In the past, Jinx has given a cogent argument as to why the procedure arity is
important for enabling implementors to experiment with upward compatible
versions of the core language. In essence, the idea is that one might want to
create an upward compatible version of a function which returns more values
than the one specified in RNRS. Since our proposal requires that the
return-arity of the generator be compatible with the arity of the receiver,
this can only be done if the generator can determine the arity of the receiver
and return an appropriate number of values. I personally find this argument
persuasive.
Note: I think a useful extension of apply-values is
(apply-values receiver generator . generator-args)
This might me a useful addition to the yellow pages; but, I would oppose making
this form op apply-values the required one.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂22-Aug-89 1339 mkatz@sesame.stanford.edu Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89 13:39:32 PDT
Received: from sesame.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA03764; Tue, 22 Aug 89 15:59:21 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA00379; Tue, 22 Aug 89 12:58:10 PDT
Date: Tue, 22 Aug 89 12:58:10 PDT
From: mkatz@sesame.stanford.edu (Morris Katz)
Message-Id: <8908221958.AA00379@sesame.Stanford.EDU>
To: cph@zurich.ai.mit.edu
Cc: ramsdell@linus.mitre.org, rrrs-authors@life.ai.mit.edu
In-Reply-To: Chris Hanson's message of Mon, 21 Aug 89 17:33:49 edt <8908212133.AA24382@zurich.ai.mit.edu>
Subject: Multiple values for R4RS.
Date: Mon, 21 Aug 89 17:33:49 edt
From: cph@zurich.ai.mit.edu (Chris Hanson)
From: ramsdell@linus.mitre.org
Date: Mon, 21 Aug 89 08:15:36 EDT
I've been using a similar interface for multiple values for about a
year now, the major difference being that instead of `apply-values'
there is an operation `with-values' which has these two arguments in
the opposite order.
I personally also favor the with-values order of generator and then receiver as
opposed to the apply-values order. Mike and I chose the apply-values order for
consistency with the regularization of procedures in Scheme. Since the
regularization of apply has been nixed, there remains no reason for the
apply-values order.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂22-Aug-89 1359 mkatz@sesame.stanford.edu Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89 13:59:33 PDT
Received: from sesame.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA03898; Tue, 22 Aug 89 16:10:19 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA00404; Tue, 22 Aug 89 13:09:03 PDT
Date: Tue, 22 Aug 89 13:09:03 PDT
From: mkatz@sesame.stanford.edu (Morris Katz)
Message-Id: <8908222009.AA00404@sesame.Stanford.EDU>
To: harris%hplwhh@hplabs.hp.com
Cc: ramsdell@linus.mitre.org, rrrs-authors@life.ai.mit.edu
In-Reply-To: Warren Harris's message of Mon, 21 Aug 89 15:23:33 PDT <8908212223.AA14032@hplwhh.HPL.HP.COM>
Subject: Multiple values for R4RS.
Date: Mon, 21 Aug 89 15:23:33 PDT
From: Warren Harris <harris%hplwhh@hplabs.hp.com>
Your proposal doesn't say what happens when the number of values
expected by the receiver is different from the number the generator
produces. A simple case is when multiple values are returned and one
is expected:
(cons (values 1 2) 3)
=> (1 . 3)
=> (<?> . 3)
=> <error>
I believe that we explicitly stated that the return-arity must be compatible
with the arity of the receiver. If we forget about rest arguments for a
moment, compatible was defined as identical. In the case above, the arity of
the implicit continuation to cons is 1 and the return-arity of values is 2, so
there is an arity incompatibility. We proposed that arity incompatibilities
are an error (not signal an error). This leaves open the ability for some
implementors to create extensions to multiple values which are not strict
without violating RNRS.
extensions that some
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂22-Aug-89 1415 jinx@hpesogg.hp.com Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89 14:15:36 PDT
Received: from sde.hp.com (hp-sde.sde.hp.com) by life.ai.mit.edu (4.1/AI-4.10) id AA04404; Tue, 22 Aug 89 16:50:49 EDT
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA22154; Tue, 22 Aug 89 13:17:22 pdt
Message-Id: <8908222017.AA22154@sde.hp.com>
Received: by hpesogg; Tue, 22 Aug 89 13:16:43 pdt
Date: Tue, 22 Aug 89 13:16:43 pdt
From: Guillermo J. Rozas <jinx@hpesogg.hp.com>
To: dyb@iuvax.cs.indiana.edu
Cc: rrrs-authors@life.ai.mit.edu
In-Reply-To: R. Kent Dybvig's message of Tue, 22 Aug 89 13:51:43 -0500 <8908221851.AA02931@life.ai.mit.edu>
Subject: Multiple values for R4RS.
Reply-To: jinx%hpesogg@sde.hp.com
The predicate "accepts?" seems a little like the (rejected) predicate
"continuation?". A procedure may not complain "up front" about a given
number of arguments, but may complain at some later time. Or it may
accept any number of arguments, but ignore all but the first few. I
don't see how "accepts?" can be generally useful if it breaks down in
these cases.
This is like saying that a given object may pass a PAIR? test yet when
given to a list operation, the operation will flame. Just because it
does not cover all cases, it does not mean that it is useless. Are
you advocating for removing PAIR? from the language?
∂22-Aug-89 1432 jinx@hpesogg.hp.com Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89 14:31:48 PDT
Received: from sde.hp.com (hp-sde.sde.hp.com) by life.ai.mit.edu (4.1/AI-4.10) id AA04470; Tue, 22 Aug 89 16:59:39 EDT
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA22411; Tue, 22 Aug 89 13:31:40 pdt
Message-Id: <8908222031.AA22411@sde.hp.com>
Received: by hpesogg; Tue, 22 Aug 89 13:31:00 pdt
Date: Tue, 22 Aug 89 13:31:00 pdt
From: Guillermo J. Rozas <jinx@hpesogg.hp.com>
To: ramsdell@linus.mitre.org
Cc: rrrs-authors@life.ai.mit.edu, ramsdell@linus.mitre.org
In-Reply-To: ramsdell@linus.mitre.org's message of Tue, 22 Aug 89 14:00:07 EDT <8908221800.AA08733@huxley.mitre.org>
Subject: Multiple values for R4RS.
Reply-To: jinx%hpesogg@sde.hp.com
[2] Do you think VALUES and APPLY-VALUES as defined reflect existing
practice? For example, in T, VALUES = RETURN, and APPLY-VALUES =
(LAMBDA (X Y) (RECEIVE-VALUES Y X)), and MIT Scheme has the
functionality.
MIT Scheme does not quite have it. It is not integrated with
continuations at all (I don't know if T's is either). I think that it
is not worth putting in, if I cannot accomodate users who would like
Common Lisp style truncation of values, or who want to be able to port
Common Lisp code a little more easily. I find the backwards
compatibility that "truncation" offers to be the most significant
feature in multiple values, and would use CPS otherwise.
[3] Do you think VALUES and APPLY-VALUES as defined prohibit the
future inclusion of ACCEPTS? or some other proposal to deal with
incompatiable arities?
Certainly not TECHNICALLY, but it is my POLITICAL feeling, that if it
is not accepted as a complete package, it will not be accepted later.
The people who want the "restrictive" multiple values will feel no
pressure to accept it later since they will already have what they
want. I'm not asking for their semantics to be different (I've
compromised on paranoid checking by default), but I would like a
little compromise on everyone else's part.
I view ACCEPTS? as a harmless little addition, and don't understand
what the fuss is all about.
[4] Do you believe VALUES and APPLY-VALUES should be excluded from
Scheme solely because there is no agreement on how to deal with
incompatiable arities?
That is the reason why they have been excluded up to now. Perhaps a
compromise is not possible.
∂22-Aug-89 1445 @relay.cs.net,@tektronix.tek.com:adams@tekchips.labs.tek.com Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89 14:45:03 PDT
Received: from MIT.EDU (MIT.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA04654; Tue, 22 Aug 89 17:15:52 EDT
Received: from RELAY.CS.NET by MIT.EDU with SMTP
id AA03014; Tue, 22 Aug 89 17:15:40 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa08811; 22 Aug 89 17:12 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
id AA20162; Tue, 22 Aug 89 14:15:05 PDT
Received: by tekirl.labs.tek.com (5.51/7.1)
id AA26560; Tue, 22 Aug 89 14:13:00 PDT
Received: by tekchips.LABS.TEK.COM (5.51/6.24)
id AA24785; Tue, 22 Aug 89 14:15:28 PDT
Date: Tue, 22 Aug 89 14:15:28 PDT
From: Norman Adams <adams%tekchips.labs.tek.com@relay.cs.net>
Message-Id: <8908222115.AA24785@tekchips.LABS.TEK.COM>
To: jinx%hpesogg@sde.hp.com
Cc: ramsdell%linus.mitre.org@relay.cs.net,
rrrs-authors%life.ai.mit.edu@relay.cs.net
Subject: Multiple values for R4RS.
From: ramsdell@linus.mitre.org
Maybe there is enough consensus to allow agreement on the
non-controversial aspects of multiple values for R4RS. What do people
think about adding only VALUES and APPLY-VALUES?
I'd take this, or VALUES and WITH-VALUES.
From: jinx%hpesogg@sde.hp.COM
I don't think they are worth adding if ACCEPTS? is not included as
well. ...
This is an extreme position. The proposed functionality is
useful even in the absence of ACCEPTS?
From: Morris Katz <mkatz@sesame.stanford.edu>
In the past, Jinx has given a cogent argument as to why the
procedure arity is important ...
I remain unconvinced. As a user, I have found multiple values
(without ACCEPTS?) quite useful. So, I don't think ACCEPTS? provides
super-essential functionality. As an implementor, I would prefer not
to be committed to keeping around arity information for every
procedure.
-Norman
∂22-Aug-89 1448 jinx@hpesogg.hp.com Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89 14:48:32 PDT
Received: from sde.hp.com (hp-sde.sde.hp.com) by life.ai.mit.edu (4.1/AI-4.10) id AB04683; Tue, 22 Aug 89 17:22:20 EDT
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA23597; Tue, 22 Aug 89 14:20:31 pdt
Message-Id: <8908222120.AA23597@sde.hp.com>
Received: by hpesogg; Tue, 22 Aug 89 14:19:50 pdt
Date: Tue, 22 Aug 89 14:19:50 pdt
From: Guillermo J. Rozas <jinx@hpesogg.hp.com>
To: adams@tekchips.labs.tek.com
Cc: ramsdell@linus.mitre.org, rrrs-authors@life.ai.mit.edu
In-Reply-To: Norman Adams's message of Tue, 22 Aug 89 14:15:28 PDT <8908222115.AA24785@tekchips.LABS.TEK.COM>
Subject: Multiple values for R4RS.
Reply-To: jinx%hpesogg@sde.hp.com
This is an extreme position. The proposed functionality is
useful even in the absence of ACCEPTS?
It's much less extreme than imposing a particular fascist semantics on
those who don't find it interesting or useful. Usefulness is an
aesthetic measure, and I find CPS better if I'm going to be fascist.
I remain unconvinced. As a user, I have found multiple values
(without ACCEPTS?) quite useful. So, I don't think ACCEPTS? provides
super-essential functionality. As an implementor, I would prefer not
to be committed to keeping around arity information for every
procedure.
You don't have to keep it around for every procedure. Just those
procedurs that might be given to ACCEPTS? as arguments. This may seem
silly, but I'm not kidding. This effectively means that only closures
(and not all of them) need to have this information. The MIT Scheme
compiler keeps arity information only for procedures that it
determines may be invoked from places that "don't know about them."
This turns out to be but a fraction of the total in typical code.
∂22-Aug-89 1606 mkatz%sesame.stanford.edu@relay.cs.net Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89 16:06:51 PDT
Received: from MIT.EDU (MIT.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA05225; Tue, 22 Aug 89 18:36:21 EDT
Received: from RELAY.CS.NET by MIT.EDU with SMTP
id AA03116; Tue, 22 Aug 89 18:36:11 EDT
Received: from sesame.stanford.edu by RELAY.CS.NET id aa12554;
22 Aug 89 18:36 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA00236; Tue, 22 Aug 89 15:34:50 PDT
Date: Tue, 22 Aug 89 15:34:50 PDT
From: Morris Katz <mkatz%sesame.stanford.edu@relay.cs.net>
Message-Id: <8908222234.AA00236@sesame.Stanford.EDU>
To: adams%tekchips.labs.tek.com@relay.cs.net
Cc: jinx%hpesogg@sde.hp.com, ramsdell%linus.mitre.org@relay.cs.net,
rrrs-authors%life.ai.mit.edu@relay.cs.net
In-Reply-To: Norman Adams's message of Tue, 22 Aug 89 14:15:28 PDT <8908222115.AA24785@tekchips.LABS.TEK.COM>
Subject: Multiple values for R4RS.
Date: Tue, 22 Aug 89 14:15:28 PDT
From: Norman Adams <adams%tekchips.labs.tek.com@relay.cs.net>
As an implementor, I would prefer not
to be committed to keeping around arity information for every
procedure.
I can't imagine how one could create an implementation in which the arity
information is not already present in some form for procedures that are passed
as arguments. Similarly, implicit continuations had better know something
about the number of values on which they intend to operate. Retrieving the
arity information may require some bit twiddling, but I suspect that the needed
information is always present in some form.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂22-Aug-89 1634 cph@zurich.ai.mit.edu Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89 16:34:29 PDT
Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA05339; Tue, 22 Aug 89 19:06:45 EDT
Received: from localhost by zurich.ai.mit.edu; Tue, 22 Aug 89 19:03:31 edt
Date: Tue, 22 Aug 89 19:03:31 edt
From: cph@zurich.ai.mit.edu (Chris Hanson)
Message-Id: <8908222303.AA04769@zurich.ai.mit.edu>
To: jinx%hpesogg@sde.hp.com
Cc: rrrs-authors@life.ai.mit.edu
In-Reply-To: Guillermo J. Rozas's message of Tue, 22 Aug 89 14:19:50 pdt <8908222120.AA23597@sde.hp.com>
Subject: Multiple values for R4RS.
Date: Tue, 22 Aug 89 14:19:50 pdt
From: Guillermo J. Rozas <jinx@hpesogg.hp.com>
This is an extreme position. The proposed functionality is
useful even in the absence of ACCEPTS?
It's much less extreme than imposing a particular fascist semantics on
those who don't find it interesting or useful.
I agree, with Norman, that the proposed functionality is useful in the
absence of `accepts?'. However, tossing around words like "extreme"
and "fascist" in this fashion seems hypocritical. Aside from the
differing emotional charges attached to these phrases, both seem to
have the same purpose: discrediting the opposition by distancing them
from the hypothetical "middle ground" (or "moral majority" if you
prefer the three-red-stars-extra-spicy emotional charge). Let's try
not to make arguments that presume knowledge of the consensus.
As an aside, I have no objection to implementing `accepts?'; I think
that it is very useful, whether or not you have multiple values. But
I dislike that particular name because it is too vague; I'd prefer
something more like `procedure-accepts?' or (as in MIT Scheme)
`procedure-arity-valid?'.
[2] Do you think VALUES and APPLY-VALUES as defined reflect existing
practice? For example, in T, VALUES = RETURN, and APPLY-VALUES =
(LAMBDA (X Y) (RECEIVE-VALUES Y X)), and MIT Scheme has the
functionality.
MIT Scheme does not quite have it. It is not integrated with
continuations at all (I don't know if T's is either). I think that it
is not worth putting in, if I cannot accomodate users who would like
Common Lisp style truncation of values, or who want to be able to port
Common Lisp code a little more easily. I find the backwards
compatibility that "truncation" offers to be the most significant
feature in multiple values, and would use CPS otherwise.
I disagree with this statement -- multiple values have usefulness
independent of the "truncation" feature, and I feel they are worth
having anyway. Despite the fact that MIT Scheme's multiple values are
not fully implemented, I have found them quite useful and I have
written much code that uses them.
CL's handling of "extra" values is distasteful to me, because it makes
the standard behavior complicated; I think that values should be
discarded only when that is explicitly stated by the code. This is
not to say that I would be extremely upset should such a semantics be
adopted, because I would just avoid using "truncation". But on
aesthetic grounds I would prefer something simpler.
∂22-Aug-89 1713 jinx@hpesogg.hp.com Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89 17:13:51 PDT
Received: from sde.hp.com (hp-sde.sde.hp.com) by life.ai.mit.edu (4.1/AI-4.10) id AA05583; Tue, 22 Aug 89 19:44:24 EDT
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA27806; Tue, 22 Aug 89 16:44:08 pdt
Message-Id: <8908222344.AA27806@sde.hp.com>
Received: by hpesogg; Tue, 22 Aug 89 16:43:26 pdt
Date: Tue, 22 Aug 89 16:43:26 pdt
From: Guillermo J. Rozas <jinx@hpesogg.hp.com>
To: cph@zurich.ai.mit.edu
Cc: rrrs-authors@life.ai.mit.edu
In-Reply-To: Chris Hanson's message of Tue, 22 Aug 89 19:03:31 edt <8908222303.AA04769@zurich.ai.mit.edu>
Subject: Multiple values for R4RS.
Reply-To: jinx%hpesogg@sde.hp.com
CL's handling of "extra" values is distasteful to me, because it makes
the standard behavior complicated; I think that values should be
discarded only when that is explicitly stated by the code. This is
not to say that I would be extremely upset should such a semantics be
adopted, because I would just avoid using "truncation". But on
aesthetic grounds I would prefer something simpler.
I don't object to this position. I object to trying to force this
position down my throat.
∂22-Aug-89 1740 @relay.cs.net,@tektronix.tek.com:adams@tekchips.labs.tek.com Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89 17:40:40 PDT
Received: from MIT.EDU (MIT.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA05739; Tue, 22 Aug 89 20:12:27 EDT
Received: from RELAY.CS.NET by MIT.EDU with SMTP
id AA03209; Tue, 22 Aug 89 20:12:16 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa16619; 22 Aug 89 20:11 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
id AA26764; Tue, 22 Aug 89 17:13:40 PDT
Received: by tekirl.labs.tek.com (5.51/7.1)
id AA13649; Tue, 22 Aug 89 17:11:35 PDT
Received: by tekchips.LABS.TEK.COM (5.51/6.24)
id AA26483; Tue, 22 Aug 89 17:14:03 PDT
Date: Tue, 22 Aug 89 17:14:03 PDT
From: Norman Adams <adams%tekchips.labs.tek.com@relay.cs.net>
Message-Id: <8908230014.AA26483@tekchips.LABS.TEK.COM>
To: jinx%hpesogg@sde.hp.com,
Morris Katz <mkatz%sesame.stanford.edu@relay.cs.net>
Cc: rrrs-authors%life.ai.mit.edu@relay.cs.net, adams@tekchips.labs
In-Reply-To: "Guillermo J. Rozas"'s message of Tue, 22 Aug 89 14:19:50 pdt <8908222120.AA23597@sde.hp.com>
Subject: Multiple values for R4RS.
From: adams@tekchips.LABS.TEK.COM
I would prefer not
to be committed to keeping around arity information for every
procedure.
From: jinx@hpesogg.hp.COM
You don't have to keep it around for every procedure.
I know. And this is a side issue. I want multiple values, and I don't
want to get hung up on ACCEPTS?.
If you are interested in the side issue, here are my thoughts:
The requirement that some procedures support ACCEPTS? still imposes
constraints on the implementation. You must have a representation of
procedures that can support ACCEPTS? As an implementor, this is the
sort of language-imposed restriction I have found useful to eliminate.
From: mkatz%sesame.stanford.edu
I can't imagine how one could create an implementation in which the arity
information is not already present in some form for procedures that
are passed
Sure, it is present in some form.
Perhaps each procedure is responsible for coping with wrong number of
arguments passed in. Somewhere in the procedure's code are
instructions that perform the check. The information is there, but
with a sufficiently clever compiler -- the sort of implementation I
find most interesting -- finding that information could be
impractical, if not intractable.
-Norman
∂22-Aug-89 1824 @spencer.cs.uoregon.edu:will@cs.uoregon.edu multiple values
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89 18:24:10 PDT
Received: from skinner.cs.uoregon.edu by life.ai.mit.edu (4.1/AI-4.10) id AA06118; Tue, 22 Aug 89 21:07:08 EDT
Received: from spencer.cs.uoregon.edu by skinner.cs.uoregon.edu with SMTP
(5.59++/IDA-1.2.8) id AA23975; Tue, 22 Aug 89 18:07:08 PDT
Received: by spencer.cs.uoregon.edu; Tue, 22 Aug 89 18:07:02 PDT
Date: Tue, 22 Aug 89 18:07:02 PDT
From: will@cs.uoregon.edu
Message-Id: <8908230107.AA29487@spencer.cs.uoregon.edu>
To: rrrs-authors@life.ai.mit.edu
Subject: multiple values
Morry Katz:
I can't imagine how one could create an implementation in which the arity
information is not already present in some form for procedures that are
passed as arguments. Similarly, implicit continuations...
Passing an incorrect number of arguments to a procedure isn't required to
signal an error, so procedures don't have to check it. Hence the arity may
not be retrievable through any amount of bit-twiddling. Also, why should
the run-time representation of (lambda args #t) include any bits that
indicate the number of arguments it expects? As a third example, the
variety and complexity of code sequences emitted by multiple compilers
may make the arity unrecoverable when embedded within code. Similarly
for continuations.
That said, I don't think ACCEPTS? would be an unreasonable burden on any
implementor. But it's certainly a burden that doesn't exist now.
Chris Hanson:
I agree, with Norman, that the proposed functionality is useful in the
absence of `accepts?'.
I agree with Chris and Norman.
Chris Hanson:
...multiple values have usefulness independent of the "truncation"
feature, and I feel they are worth having anyway.
I agree again. I believe the multiple values proposal being considered
allows the "truncation" feature as an extension: the critical property
is that (VALUES E) is always equivalent to E.
Peace, Will
∂22-Aug-89 1838 @spencer.cs.uoregon.edu:will@cs.uoregon.edu theology; MAX and MIN
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89 18:37:57 PDT
Received: from skinner.cs.uoregon.edu by life.ai.mit.edu (4.1/AI-4.10) id AA06133; Tue, 22 Aug 89 21:08:19 EDT
Received: from spencer.cs.uoregon.edu by skinner.cs.uoregon.edu with SMTP
(5.59++/IDA-1.2.8) id AA23985; Tue, 22 Aug 89 18:08:32 PDT
Received: by spencer.cs.uoregon.edu; Tue, 22 Aug 89 18:08:24 PDT
Date: Tue, 22 Aug 89 18:08:24 PDT
From: will@cs.uoregon.edu
Message-Id: <8908230108.AA29492@spencer.cs.uoregon.edu>
To: rrrs-authors@life.ai.mit.edu
Subject: theology; MAX and MIN
Note to Jim Miller: My mail to you has bounced. How did your poll on
this issue come out?
Guy Steele Jr:
Theologically or politically speaking, under the first view inexact numbers
strive to obey laws acknowledged to be perfect, but to a greater or lesser
degree are each in a state of sin. Under the second view they are all
model citizens, adhering perfectly to their own laws which, however, are
acknowledged not to be ideal but merely the best one can do in this
imperfect and finite world.
In the imperfect world I live in, the supremum implied by the phrase
"the best one can do" is even less likely to exist than in the world of
computer arithmetic.
Theologically speaking, Guy's new proposal has the same problem as his old
proposal: It introduces two new demons to undermine a user's faith in
exact numbers. Only the names have changed: now the demons are called
LARGEST and SMALLEST. The damage done by these two procedures won't be
ameliorated by having exactness-preserving SUP and INF as well. For
simplicity, I say that if MAX and MIN, by whatever names, are going to be
exceptions to the perfect rules of exactness, then let's just acknowledge
them as exceptions and to hell, theologically speaking, with the sinfully
striving exactness-preserving versions.
Guy Steele Jr:
But my point of view is that the MAX operation per se, like other C
operators is *not* polymorphic. They operate only on two ints or
two floats. The type mechanism enforces this requirement by inserting
coercions; the point is that these coercions are outside the control
of the implementation of the operation itself, and therefore not
properly a part of them. In exactly the same way that max(2.5, 1000)
in an int context ends up having a coercion inserted, so the coercion
that converts 1000 to a float is artificially inserted.
It doesn't matter how you look at it. My point is that, contrary
to some recent discussion in RRRS-AUTHORS, experience with mainstream
programming languages has conditioned programmers to expect expressions
like (MAX 2.5 1000) to evaluate to an inexact number. I pointed this
out to dispose of a bogus argument, not to argue that programmers'
expectations should decide the issue. Expectations formed by other
languages aren't necessarily met by arithmetic in Scheme, precisely
because arithmetic in Scheme is more generic (polymorphic, if you will)
than in other languages.
Peace, Will
∂22-Aug-89 1842 jinx@hpesogg.hp.com Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89 18:42:06 PDT
Received: from sde.hp.com (hp-sde.sde.hp.com) by life.ai.mit.edu (4.1/AI-4.10) id AA05920; Tue, 22 Aug 89 20:44:41 EDT
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA29418; Tue, 22 Aug 89 17:43:51 pdt
Message-Id: <8908230043.AA29418@sde.hp.com>
Received: by hpesogg; Tue, 22 Aug 89 17:43:10 pdt
Date: Tue, 22 Aug 89 17:43:10 pdt
From: Guillermo J. Rozas <jinx@hpesogg.hp.com>
To: adams@tekchips.labs.tek.com
Cc: mkatz%sesame.stanford.edu@relay.cs.net, rrrs-authors@life.ai.mit.edu,
adams@tekchips.labs
In-Reply-To: Norman Adams's message of Tue, 22 Aug 89 17:14:03 PDT <8908230014.AA26483@tekchips.LABS.TEK.COM>
Subject: Multiple values for R4RS.
Reply-To: jinx%hpesogg@sde.hp.com
Perhaps each procedure is responsible for coping with wrong number of
arguments passed in. Somewhere in the procedure's code are
instructions that perform the check. The information is there, but
with a sufficiently clever compiler -- the sort of implementation I
find most interesting -- finding that information could be
impractical, if not intractable.
With a sufficiently clever compiler, the information should not be in
the code, since all checks have been done at compile time :-)
The MIT compiler used to output instructions to do arity checks at
runtime, but now the dynamic linker checks for arity mismatches when
definitions or assignments occur, thus rendering the runtime check a
waste of time in most of the cases. The only cases where arity needs
to be checked at runtime in (compiled) MIT Scheme are things like
((car some-pair) arg1 arg2 arg3)
where the shape of the car of SOME-PAIR is not known at compile time.
The arity information is present in fixed format in "external
procedures" so that the linker (a fixed program) can check for
mismatches and create the appropriate trampolines at run time. The
information is encoded so that the runtime check in cases like the
above is very fast when the number of arguments passed matches exactly
the number of arguments expected, and can be coded in-line, although
we don't do it right now.
The arity information only makes the output code be slightly larger in
a few cases, but hardly affects the time performance. Except for
garbage collection time (compiled code objects are slightly larger),
and closure creation time (the closures must contain the arity
information if they are passed to "unknown" places), the time penalty
is very small, and I suspect that on the average, it is smaller than
in your model.
In our implementation we multiplex this information with debugging
information (how many words are on the stack "on top" of a return
address, the kind of compiled entry point this is, etc), and it takes
16 bits per external entry point (whether a compiled procedure,
expression, return address or other), which we feel is not an excesive
space penalty.
Another possibility is to encode the arity information redundantly.
One encoding is for the actual runtime check, the other for ACCEPTS?
or similar procedures. Note that this redundant encoding need not
take any space in the runtime image, since the compiler can produce
another object when compiling code, associating PCs to arities, and
this can be kept on an external "file", loaded only when someone uses
ACCEPTS?
In general, I find that implementation efficiency arguments based on
details of particular implementation strategies don't carry much
weight because two days later someone finds a different implementation
strategy that jiggles the trade-offs, but maintains the semantics.
Note that I don't need ACCEPTS? to be particularly efficient, since it
will only be used to provide an expensive portability hook.
Implementations that are sincerely interested in supporting less
strict return arity checking will want to provide a more efficient
primitive mechanism.
∂22-Aug-89 2037 dyb@iuvax.cs.indiana.edu Re: Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89 20:36:52 PDT
Received: from iuvax.cs.indiana.edu by life.ai.mit.edu (4.1/AI-4.10) id AA07736; Tue, 22 Aug 89 23:14:59 EDT
Message-Id: <8908230314.AA07736@life.ai.mit.edu>
Received: by iuvax.cs.indiana.edu
Date: Tue, 22 Aug 89 22:15:25 -0500
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
To: jinx%hpesogg@sde.hp.com
Subject: Re: Multiple values for R4RS.
Cc: rrrs-authors@life.ai.mit.edu
> The predicate "accepts?" seems a little like the (rejected) predicate
> "continuation?". A procedure may not complain "up front" about a given
> number of arguments, but may complain at some later time. Or it may
> accept any number of arguments, but ignore all but the first few. I
> don't see how "accepts?" can be generally useful if it breaks down in
> these cases.
>
> This is like saying that a given object may pass a PAIR? test yet when
> given to a list operation, the operation will flame. Just because it
> does not cover all cases, it does not mean that it is useless. Are
> you advocating for removing PAIR? from the language?
There is a difference that I'm surprised you don't see. When "pair?"
returns #t for an object, I know that I can use "car" or "cdr" without
causing an error. No similar claim can be made for "accepts?".
If we decide to add "accepts?" to the language, we would have to say
that an implementation is free to return #t if it cannot determine
whether or not a given number of arguments is accepted by a given
procedure. An implementation might even define "accepts?" as:
(lambda (procedure arity) #t)
This may seem to water down the predicate, but it only makes explicit
that which must already be true.
Kent
∂22-Aug-89 2052 dyb@iuvax.cs.indiana.edu Re: Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89 20:52:11 PDT
Received: from iuvax.cs.indiana.edu by life.ai.mit.edu (4.1/AI-4.10) id AA07971; Tue, 22 Aug 89 23:30:36 EDT
Message-Id: <8908230330.AA07971@life.ai.mit.edu>
Received: by iuvax.cs.indiana.edu
Date: Tue, 22 Aug 89 22:31:06 -0500
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
To: jinx%hpesogg@sde.hp.com
Subject: Re: Multiple values for R4RS.
Cc: rrrs-authors@life.ai.mit.edu
> Certainly not TECHNICALLY, but it is my POLITICAL feeling, that if it
> is not accepted as a complete package, it will not be accepted later.
> The people who want the "restrictive" multiple values will feel no
> pressure to accept it later since they will already have what they
> want. I'm not asking for their semantics to be different (I've
> compromised on paranoid checking by default), but I would like a
> little compromise on everyone else's part.
As long as we are considering the issues politically rather than
technically, how would you feel about the following compromises?
* let's add "values" and "with-values" (or "apply-values") and
change the name of the so-called "named let" to "recur".
* let's add "accepts?" and remove the requirement that Scheme
be case insensitive.
These may be considered together or separately, as you desire.
Kent
∂22-Aug-89 2105 dyb@iuvax.cs.indiana.edu Re: multiple values
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89 21:05:38 PDT
Received: from iuvax.cs.indiana.edu by life.ai.mit.edu (4.1/AI-4.10) id AA08061; Tue, 22 Aug 89 23:45:04 EDT
Message-Id: <8908230345.AA08061@life.ai.mit.edu>
Received: by iuvax.cs.indiana.edu
Date: Tue, 22 Aug 89 22:45:40 -0500
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
To: rrrs-authors@life.ai.mit.edu, will@cs.uoregon.edu
Subject: Re: multiple values
> I agree again. I believe the multiple values proposal being considered
> allows the "truncation" feature as an extension: the critical property
> is that (VALUES E) is always equivalent to E.
And this is the feature I'm most critical of. Unless an implementation
does support the truncation feature, I don't see any reason why we should
require that "(values e)" be equivalent to "e". I would like to feel
free to signal an error if "(values e)" is returned to a context that
is not prepared to accept multiple values.
Kent
∂23-Aug-89 0440 jinx@hpesogg.hp.com multiple values
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 04:40:39 PDT
Received: from sde.hp.com ([15.255.152.2]) by life.ai.mit.edu (4.1/AI-4.10) id AA00828; Wed, 23 Aug 89 06:57:53 EDT
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA06357; Wed, 23 Aug 89 00:00:05 pdt
Message-Id: <8908230700.AA06357@sde.hp.com>
Received: by hpesogg; Tue, 22 Aug 89 23:51:29 pdt
Date: Tue, 22 Aug 89 23:51:29 pdt
From: Guillermo J. Rozas <jinx@hpesogg.hp.com>
To: dyb@iuvax.cs.indiana.edu
Cc: rrrs-authors@life.ai.mit.edu, will@cs.uoregon.edu
In-Reply-To: R. Kent Dybvig's message of Tue, 22 Aug 89 22:45:40 -0500 <8908230345.AA08061@life.ai.mit.edu>
Subject: multiple values
Reply-To: jinx%hpesogg@sde.hp.com
And this is the feature I'm most critical of. Unless an implementation
does support the truncation feature, I don't see any reason why we should
require that "(values e)" be equivalent to "e". I would like to feel
free to signal an error if "(values e)" is returned to a context that
is not prepared to accept multiple values.
The question is whether you want to catch your personal errors, or you
want to catch everyone else's errors.
1) If you want to catch everyone else's errors, you don't gain
anything by making this additional restriction. No one but you, and I
suspect not even you, is going to write the following code:
(with-values
(lambda ()
<some code>)
(lambda (k) ; Single value expected
<more code>))
Given this, everyone (except perhaps you) will redefine values in the
following way:
(define (lax-values . all)
(if (not (singleton? all))
(apply values all)
(car all)))
Furthermore, if ACCEPTS? is in the language, people will do the
following
(define (lax-with-values generator recvr)
(if (not (arity-is-1? recvr))
(with-values generator recvr)
(let ((value (generator)))
(recvr value))))
Where
(define (singleton? list)
(and (pair? list)
(null? (cdr list))))
(define (arity-is-1? procedure)
(and (accepts? procedure 1)
(not (accepts? procedure 0))
(not (accepts? procedure 2))))
and you won't gain any error checking on everyone else's code.
[PS: I realize that lax-values above has a bug, but it will do for
most people. The bug can be fixed with ACCEPTS? in the following way:
(define (lax-values . all)
(if (not (singleton? all))
(apply values all)
(call-with-current-continuation
(lambda (k)
(if (arity-is-1? k)
(car all)
(apply values all))))))
]
2) If you want to catch your own errors, you (personally) can use the
following versions instead:
(define (dyb-with-values generator recvr)
(with-values generator
(lambda all
(if (< (length all) 2)
(error "dyb-with-values: Mismatch" all)
(apply recvr (cddr all))))))
(define (dyb-values . all)
(apply values (cons 'ignore-0 (cons 'ignore-1 all))))
∂23-Aug-89 0458 ramsdell@linus.mitre.org Just add WITH-VALUES and VALUES.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 04:58:20 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA01612; Wed, 23 Aug 89 07:39:26 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA18144; Wed, 23 Aug 89 07:33:06 EDT
Posted-Date: Wed, 23 Aug 89 07:33:02 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA09643; Wed, 23 Aug 89 07:33:03 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8908231133.AA09643@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Cc: ramsdell@linus.mitre.org
Subject: Just add WITH-VALUES and VALUES.
In-Reply-To: Your message of Tue, 22 Aug 89 15:12:00 -0400.
<19890822191226.5.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Wed, 23 Aug 89 07:33:02 EDT
I sounds to me like the WITH-VALUES is the preferred name and the
generator should be the first argument to WITH-VALUES. So here is my
amended proposal.
------------------------------ WITH-VALUES Proposal.
(values obj ...) essential procedure
Returns 0 or more values to a receiving procedure (See with-values).
(values) => returns zero (no) values
(values 1) => returns a single value, 1
(values 1 'a) => returns two values, 1 and the symbol a
(with-values generator receiver) essential procedure
Returns the result of applying the procedure 'receiver' to the values
produced by calling procedure 'generator' with no arguments. It is an
error if 'receiver' cannot be applied to the number of values returned
by 'generator' or if 'generator' cannot be called with zero arguments.
(with-values
(lambda ()
(values 1 2))
cons) => (1 . 2)
--------------------------------
As for the politics, consider this proposal as the best oportunity for
a compromise. We ask Kent Dybvig to accept the critical property that
(VALUES E) is always equivalent to E and we ask Guillermo Rozas to
accept no agreement can currently be reached about an arity checking
procedure. Please do not hold WITH-VALUES and VALUES hostage for they
really do represent existing practice, and many programmers use these
procedures. The art of politics is compromise. What say we give it a try?
John
PS. My preferred name for WITH-VALUES is CPS-CALL, but I would not
let the preferrence stand in the way of a compromise!
∂23-Aug-89 0458 jinx@hpesogg.hp.com Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 04:57:10 PDT
Received: from sde.hp.com (hp-sde.sde.hp.com) by life.ai.mit.edu (4.1/AI-4.10) id AA01635; Wed, 23 Aug 89 07:40:25 EDT
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA04990; Tue, 22 Aug 89 23:13:16 pdt
Message-Id: <8908230613.AA04990@sde.hp.com>
Received: by hpesogg; Tue, 22 Aug 89 23:12:31 pdt
Date: Tue, 22 Aug 89 23:12:31 pdt
From: Guillermo J. Rozas <jinx@hpesogg.hp.com>
To: dyb@iuvax.cs.indiana.edu
Cc: rrrs-authors@life.ai.mit.edu
In-Reply-To: R. Kent Dybvig's message of Tue, 22 Aug 89 22:31:06 -0500 <8908230330.AA02675@sde.hp.com>
Subject: Multiple values for R4RS.
Reply-To: jinx%hpesogg@sde.hp.com
As long as we are considering the issues politically rather than
technically, how would you feel about the following compromises?
* let's add "values" and "with-values" (or "apply-values") and
change the name of the so-called "named let" to "recur".
Clearly these are independent issues. The issues with multiple values
are not. I PERSONALLY find multiple values useless (other people
obviously disagree) if they don't give me the capability that I want.
I don't think you can link named let to multiple values in a similar
way.
* let's add "accepts?" and remove the requirement that Scheme
be case insensitive.
Again, you are being random. I can offer you many of these random
compromises too (how about trading "named let" -> "recur" for "begin"
-> "progn" ?).
∂23-Aug-89 0508 jinx@hpesogg.hp.com Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 05:08:39 PDT
Received: from sde.hp.com (hp-sde.sde.hp.com) by life.ai.mit.edu (4.1/AI-4.10) id AA01856; Wed, 23 Aug 89 07:49:18 EDT
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA04907; Tue, 22 Aug 89 23:08:46 pdt
Message-Id: <8908230608.AA04907@sde.hp.com>
Received: by hpesogg; Tue, 22 Aug 89 23:08:03 pdt
Date: Tue, 22 Aug 89 23:08:03 pdt
From: Guillermo J. Rozas <jinx@hpesogg.hp.com>
To: dyb@iuvax.cs.indiana.edu
Cc: rrrs-authors@life.ai.mit.edu
In-Reply-To: R. Kent Dybvig's message of Tue, 22 Aug 89 22:15:25 -0500 <8908230314.AA02393@sde.hp.com>
Subject: Multiple values for R4RS.
Reply-To: jinx%hpesogg@sde.hp.com
There is a difference that I'm surprised you don't see. When "pair?"
returns #t for an object, I know that I can use "car" or "cdr" without
causing an error. No similar claim can be made for "accepts?".
There is an analogy that I'm surprised you don't see: :-)
Just because (pair? x) is #t, I can't guarantee that (cddr x) won't
error.
Similarly, just because (accepts? p 3) evaluates to #t I can't guarantee
that (accepts? cons 3) even if
(define (p . args)
(apply cons args))
As another example, you would certainly say that I was being confused
if I complained about the following program signalling an error
(define (foo x y)
(if (and (list? x) (> (length x) 1))
(begin
(set-cdr! x y)
(cddr x))))
(foo (list 1 2) 'joe)
Further processing after initial invocation is not guaranteed to be
correct. It depends on exactly what the program does.
Your argument seems to be that ACCEPTS? is an ill-defined concept
because when we actually give that many arguments the process may
still error out (for example if the types or range of the arguments
are incorrect).
Accepts? is not a general purpose error-hook. It does not attempt to
find out whether a given process will terminate or error out. It is
just telling me whether the signature of a given procedure object (not
the corresponding mathematical function) is such that it is legal to
give it 3 arguments. It is almost "syntactic".
If we decide to add "accepts?" to the language, we would have to say
that an implementation is free to return #t if it cannot determine
whether or not a given number of arguments is accepted by a given
procedure. An implementation might even define "accepts?" as:
Again, if you don't try to make it transitive, and a Turing oracle, it
is perfectly well defined whether a given procedure object accepts a
given number of arguments or not. I would be very annoyed (and
consider the implementation to be in error) if
(accepts? p 3) -> #t
and then
(p 'a 'b 'c) -> Error from apply: Too many (or few) arguments to p
It is perfectly fine if
(accepts? p 3) -> #t
and then
(p 'a 'b 'c) -> Error from apply: Too many (or few) arguments to q
where (eqv? p q) -> #f
The further constraint that is needed to make me happy is that
(define (check-2 n)
(with-values
(lambda ()
(call-with-current-continuation
(lambda (cont)
(values (accepts? cont n) 'ignore))))
(lambda (x y)
x)))
(check-2 2) -> #t
(and (integer? m)
(not (negative? m))
(not (= m 2))
(check-2 m)) -> #f
For all objects m.
Analogously for check-0, check-1, check-3, etc.
∂23-Aug-89 0853 @mc.lcs.mit.edu,@gateway.think.com:gls@think.com Numbers
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 08:51:28 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA03979; Wed, 23 Aug 89 11:29:46 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa26520;
22 Aug 89 13:25 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 22 Aug 89 13:25:21 EDT
Received: from Gateway.Think.COM by mintaka.lcs.mit.edu id aa26446;
22 Aug 89 13:19 EDT
Received: from fafnir.think.com by Think.COM; Tue, 22 Aug 89 13:19:24 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Tue, 22 Aug 89 13:16:52 EDT
Received: by verdi.think.com; Tue, 22 Aug 89 13:16:40 EDT
Date: Tue, 22 Aug 89 13:16:40 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8908221716.AA01133@verdi.think.com>
To: bawden.pa@xerox.com
Cc: gls@think.com, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: bawden.pa@xerox.com's message of Mon, 21 Aug 89 17:24 PDT <19890822002405.2.ALAN@ROCKY.parc.xerox.com>
Subject: Numbers
Date: Mon, 21 Aug 89 17:24 PDT
From: bawden.pa@xerox.com
Date: Mon, 21 Aug 89 11:34:37 EDT
From: Guy Steele <gls@think.com>
I'm back from an exhausting, and therefore very restful, vacation.
Back into the fray!
I was wondering why I hadn't heard from you. I couldn't imagine that you
had given up the argument!
Here is a new proposal. Given a set of points within a partial order,
there are two interesting kinds of "max"-like operation. One is to find
some point (not necessarily within the set) that is >= all points in the
given set; this is SUP....
Another is to find some point in the set such that no point in the set is >
that point....
But the version of MAX I am advocating isn't either of these! I would
allow:
(max 1.0 549755813889) ==> 549755813888.0
Where presumably (< 549755813888.0 549755813889) is true. Thus MAX can
return an object that, according to `<', is smaller than one of the
arguments.
Now I'm sure that about half of you are shouting at your terminal about how
I couldn't -possibly- mean that, but I do. Understand me once and for all:
INEXACT NUMBERS ARE NOT NUMBERS
INEXACT NUMBERS ARE NOT NUMBERS
INEXACT NUMBERS ARE NOT NUMBERS
They do not obey the rules followed by numbers, because they cannot.
Inexact numbers only represent our -approximate- -knowledge- about numbers.
In
(max 1.0 549755813889) ==> 549755813888.0
we strongly suspect that the first number is 1, but we don't know for sure.
Thus we strongly suspect that the answer is 549755813889, but again we
don't know for sure (the first number could have actually been
549755813890). Since we don't know the answer for sure, we must return an
inexact representation of our best guess. 549755813888.0 is the closest we
can come. (The next larger might be 549755879424.0, assuming 23 bits of
floating point precision, which is not very close at all.)
Indeed, we could -specify- that MAX always ``round up'' in the inexact case
so that the result always appears greater (accroding to `<') than any of
the arguments. This would be similar to specifying that `<' must always
behave transitively. It would be a feeble attempt on our part to paper
over the ugly fact that -in- -general-, inexact numbers do not obey the
axioms of arithmetic.
I did misunderstand. Thank you for correcting me on this point. Now:
Pardon my French, but this is completely ridiculous. You are telling me
that if I compare the height of a skyscraper, accurately measured by laser
and known to be within a few microns of 1000 feet tall, with a little kid
judged by eyeball to be within four inches of three feet tall, then I
should conclude that I know the larger of the two heights to be 1000 feet
but only to within four inches.
I agree that in *some* cases the best you can do is return an inexact
representation of one's best guess. But sometimes you can tell for sure
that the answer is exact, even if some of the inputs were inexact.
In other words, I deny that the inexactness contagion used for + and * is
appropriate for MAX and MIN. Why is 549755813888.0 the closest we can
come? Only because we have made an arbitrary decision to cast the result
into a representation that reflects the inexactness of the least exact
input, regardless of whether that amount of inexactness in fact had
anything to do with the result computed.
--Guy
∂23-Aug-89 0856 @mc.lcs.mit.edu:bawden.pa@xerox.com Numbers
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 08:55:52 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA04029; Wed, 23 Aug 89 11:33:38 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa01876;
22 Aug 89 18:09 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 22 Aug 89 17:48:20 EDT
Received: from Xerox.COM by mintaka.lcs.mit.edu id aa01446; 22 Aug 89 17:43 EDT
Received: from Semillon.ms by ArpaGateway.ms ; 22 AUG 89 14:43:10 PDT
Date: Tue, 22 Aug 89 14:40 PDT
From: bawden.pa@xerox.com
Subject: Numbers
To: gls@think.com
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: <8908221716.AA01133@verdi.think.com>
Message-Id: <19890822214016.5.ALAN@ROCKY.parc.xerox.com>
Line-Fold: no
Date: Tue, 22 Aug 89 13:16:40 EDT
From: gls@Think.COM (Guy Steele)
Pardon my French, but this is completely ridiculous.
I keep hoping that if I rattle you hard enough I may be able to shake you
loose from your position. Perhaps I'm making progress...
You are telling me
that if I compare the height of a skyscraper, accurately measured by laser
and known to be within a few microns of 1000 feet tall, with a little kid
judged by eyeball to be within four inches of three feet tall, then I
should conclude that I know the larger of the two heights to be 1000 feet
but only to within four inches.
Inexact numbers do not necessarily contain a representation of the
precision with which a quantity is known. In the common case where
floating point is used, they most definitely do not. (In the rare case
where interval arithmetic is used, the bounds are known.) Thus in a
floating point implementation of inexact numbers, you cannot represent the
concepts of "within a few microns of 1000 feet" or "within four inches of
three feet". The best you can do is "perhaps 1000 feet" and "about four
feet". The MAX of these two is "perhaps 1000 feet" -- any arguments about
the precision ("within a few microns of 1000 feet" vs. "within four inches
of 1000 feet") are in the province of a numerical analyst to reason about.
What I was -actually- claiming was that the MAX of "exactly 1000 feet" and
"about four feet" is "perhaps 1000 feet". (In an implementation that used
interval arithmetic, I could indeed compute the MAX of "exactly 1000 feet"
and "within four inches of three feet" and get "exactly 1000 feet", but in
-general-, inexact arithmetic does not have this ability.)
I agree that in *some* cases the best you can do is return an inexact
representation of one's best guess. But sometimes you can tell for sure
that the answer is exact, even if some of the inputs were inexact.
Perhaps a numerical analyst can look at my program and tell me that for
sure. Perhaps if I am using interval arithmetic my implementation can tell
me that for sure. But if I am using floating point, my implementation can
-never- know that for sure.
In other words, I deny that the inexactness contagion used for + and * is
appropriate for MAX and MIN. Why is 549755813888.0 the closest we can
come? Only because we have made an arbitrary decision to cast the result
into a representation that reflects the inexactness of the least exact
input, regardless of whether that amount of inexactness in fact had
anything to do with the result computed.
It was not an "arbitrary decision" at all. 549755813888.0 is closest
because we only have 23-bit floating point to represent inexact numbers,
and the answer must be inexact. Its the best we can do. If we return an
exact number we are potentially returning an -INCORRECT- result. We don't
know the answer exactly, so we cannot return an exact number.
I would have no objection if we decided to specify that MAX would have to
round up, so that 549755879424.0 was the answer in my example. One could
argue that this was somehow a better approximation to the true answer
because it passed the `<' test. But under no circumstances can I see
allowing 549755813889 to be returned, as that would discard the important
information that the answer is not known exactly.
∂23-Aug-89 0905 dyb@iuvax.cs.indiana.edu Re: multiple values
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 09:05:46 PDT
Received: from iuvax.cs.indiana.edu by life.ai.mit.edu (4.1/AI-4.10) id AA04104; Wed, 23 Aug 89 11:40:55 EDT
Message-Id: <8908231540.AA04104@life.ai.mit.edu>
Received: by iuvax.cs.indiana.edu
Date: Wed, 23 Aug 89 10:41:22 -0500
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
To: jinx%hpesogg@sde.hp.com
Subject: Re: multiple values
Cc: rrrs-authors@life.ai.mit.edu
The question is whether you want to catch your personal errors, or you
want to catch everyone else's errors.
As an implementor, I would like to signal an error whenever someone
attempts to return (values ...) to a context where multiple values
aren't expected, or something other than (values ...) to a context
expecting multiple values. Requiring "(values e)" to be the same as
"e" makes it impossible to do this. As you pointed out in your note,
this won't affect anyone who doesn't like this behavior, since they
can always create their own versions of "values" and "with-values"
that circumvent the error checks.
Note that I'm not asking for a requirement that "(values e)" be
distinct from "e", only that we not require that "(values e)" be
the same as "e". So it doesn't rule out an implementation that
automatically truncates multiple values.
Kent
∂23-Aug-89 0925 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #180
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 09:25:07 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA03917; Wed, 23 Aug 89 11:21:58 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa06320;
17 Aug 89 10:36 EDT
Date: 17 AUG 89 09:39:51 EDT
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.mc.lcs.edu>
Subject: Scheme Digest #180
To: Scheme%mc.lcs.mit.edu@mintaka.mc.lcs.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.mc.lcs.edu
Message-Id: <8908171037.aa06320@mintaka.lcs.mit.edu>
Scheme Digest #180 17 AUG 89 09:39:51 EDT
Today's Topics:
Lisp shells
Books on Scheme
Books on Scheme
Additional function libraries for PC-Scheme...
X Scheme availability
"Scheme has data types and Lisp doesn't."
----------------------------------------------------------------------
Date: Wed, 16 Aug 89 05:16:39 EDT
From: Olin.Shivers@a.gp.cs.cmu.edu
Subject: Lisp shells
Message-ID: <8908160517.aa18074@mintaka.lcs.mit.edu>
John Lacey requested information on Lisp shells. John Ellis implemented
a shell for a PDP-11/45 running Unix in Harvard Lisp in 1979.
"A LISP SHELL"
John R. Ellis
ACM SIGPLAN Notices, Vol. 15 #5, May 1980
John Levine has a paper about using Lisp for a command language in the
same issue of SIGPLAN Notices ("Why a Lisp-Based Command Language?").
Of course, you might do well to look into the Lisp Machine interface, both
before and after the fancy Symbolics interface that allowed non-Lisp-syntax
commands. Any you might consider gnu-emacs plus all the extensions (like
monkey mode) to be a fairly reasonable shell, with lisp as an extension
language.
-Olin
------------------------------
Date: 15 Aug 89 17:43:18 GMT
From: Jonas 'Gamemaster' Mellin <mcvax!sunic!his!jonas@uunet.uu.net>
Subject: Books on Scheme
Message-Id: <261@his.UUCP>
Does anyone know a good book about Scheme?
Please answer via E-mail.
------------------------------
Date: 16 Aug 89 14:58:49 GMT
From: Adam Glass <adam@media-lab.media.mit.edu>
Subject: Re: Books on Scheme
Message-Id: <493@mit-amt.MEDIA.MIT.EDU>
jonas@his.UUCP (Jonas 'Gamemaster' Mellin) writes:
> Does anyone know a good book about Scheme?
>
> Please answer via E-mail.
Please answer via a public message in this newsgroup. I am quite interested
also.
Adam
--
"Offer me anything I ask for..."
"Anything you want."
"I want my father back, you son of a bitch." - The Princess Bride
------------------------------
Date: 16 Aug 89 15:28:04 GMT
From: Kevin Spier <usc!cs.utexas.edu!csd4.csd.uwm.edu!leah!rpi!turing.cs.rpi.edu!spierk@bloom-beacon.mit.edu>
Subject: Additional function libraries for PC-Scheme...
Message-Id: <6802@rpi.edu>
I am looking for any public domain function libraries (in source form
only) available for PC Scheme v3.0 (which is R↑3 compatible). I guess
any library which requires only R↑3 compatibility would also be fine.
Please mail directly to me and I will post a summary if others are
interested.
Thanks,
Kevin L. Spier
spierk@turing.cs.rpi.edu
Kevin L. Spier
spierk@turing.cs.rpi.edu
------------------------------
Date: 16 Aug 89 20:29:17 GMT
From: Erik Talvola <pasteur!talvola@ucbvax.berkeley.edu>
Subject: X Scheme availability
Message-Id: <TALVOLA.89Aug16132917@janus.berkeley.edu>
I have a rather old version of X-Scheme on my IBM PC (version 0.16) and
was wondering where I could obtain the most recent version, in both source
and object form. Availability by FTP would be nice, but if not, then a
BBS source would be fine. Thanks in advance.
--
+----------------------------+
! Erik Talvola | "It's just what we need... a colossal negative
! talvola@janus.berkeley.edu | space wedgie of great power coming right at us
! ...!ucbvax!janus!talvola | at warp speed." -- Star Drek
------------------------------
Date: 15 Aug 89 14:52:37 GMT
From: Jeff Dalton <mcvax!ukc!edcastle!aiai!jeff@uunet.uu.net>
Subject: Re: "Scheme has data types and Lisp doesn't."
Message-Id: <737@skye.ed.ac.uk>
In article <13120@well.UUCP> nagle@well.UUCP (John Nagle) writes:
>Common LISP has lots of declarations. But the programmer isn't required
>to provide them and the compiler implementor isn't required to make them
>do much. CLTL: [...] Not that SCHEME is really all that different.
I knew about all of the things you cite in CLtL. I still don't see
how it explains the claim that "Scheme has data types and Lisp doesn't."
-- Jeff
------------------------------
End of Scheme Digest
********************
∂23-Aug-89 0939 dyb@iuvax.cs.indiana.edu Re: Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 09:39:03 PDT
Received: from iuvax.cs.indiana.edu by life.ai.mit.edu (4.1/AI-4.10) id AA04605; Wed, 23 Aug 89 12:27:20 EDT
Message-Id: <8908231627.AA04605@life.ai.mit.edu>
Received: by iuvax.cs.indiana.edu
Date: Wed, 23 Aug 89 11:27:42 -0500
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
To: jinx%hpesogg@sde.hp.com
Subject: Re: Multiple values for R4RS.
Cc: rrrs-authors@life.ai.mit.edu
There is an analogy that I'm surprised you don't see: :-)
Just because (pair? x) is #t, I can't guarantee that (cddr x) won't
error.
Ah, but I can ask (and (pair? x) (pair? (cdr x))), and if this is #t,
then I can be certain that (cddr x) won't error.
Similarly, just because (accepts? p 3) evaluates to #t I can't guarantee
that (accepts? cons 3) even if
(define (p . args)
(apply cons args))
That's right.
Further processing after initial invocation is not guaranteed to be
correct. It depends on exactly what the program does.
Right again.
Your argument seems to be that ACCEPTS? is an ill-defined concept ...
My argument is that "accepts?" is virtually meaningless, since it is
a superficial property of the outermost level of the procedure, and there
is no way to extend it further in. If "accepts?" returns #t, so what?
Again, if you don't try to make it transitive, and a Turing oracle, it
is perfectly well defined whether a given procedure object accepts a
given number of arguments or not. I would be very annoyed (and
consider the implementation to be in error) if
(accepts? p 3) -> #t
and then
(p 'a 'b 'c) -> Error from apply: Too many (or few) arguments to p
But this is exactly what may happen if "p" does its own checking, i.e.,
if I write p as:
(lambda args
(if (> (length args) 2)
(error 'apply "Too many (or few) arguments to p")
(f args)))
Of course, "p" is representing itself as "apply" in the error message,
but I hardly see that it's relevant where the message comes from.
∂23-Aug-89 1027 mkatz%sesame.stanford.edu@relay.cs.net Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 10:27:37 PDT
Received: from MIT.EDU (MIT.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA05110; Wed, 23 Aug 89 13:09:16 EDT
Received: from RELAY.CS.NET by MIT.EDU with SMTP
id AA03906; Wed, 23 Aug 89 13:09:05 EDT
Received: from sesame.stanford.edu by RELAY.CS.NET id aa01216;
23 Aug 89 13:08 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA00319; Wed, 23 Aug 89 10:07:34 PDT
Date: Wed, 23 Aug 89 10:07:34 PDT
From: Morris Katz <mkatz%sesame.stanford.edu@relay.cs.net>
Message-Id: <8908231707.AA00319@sesame.Stanford.EDU>
To: adams%tekchips.labs.tek.com@relay.cs.net
Cc: jinx%hpesogg@sde.hp.com, mkatz%sesame.stanford.edu@relay.cs.net,
rrrs-authors%life.ai.mit.edu@relay.cs.net, adams@tekchips.labs
In-Reply-To: Norman Adams's message of Tue, 22 Aug 89 17:14:03 PDT <8908230014.AA26483@tekchips.LABS.TEK.COM>
Subject: Multiple values for R4RS.
Date: Tue, 22 Aug 89 17:14:03 PDT
From: Norman Adams <adams%tekchips.labs.tek.com@relay.cs.net>
From: mkatz%sesame.stanford.edu
I can't imagine how one could create an implementation in which the arity
information is not already present in some form for procedures that
are passed
Sure, it is present in some form.
Perhaps each procedure is responsible for coping with wrong number of
arguments passed in. Somewhere in the procedure's code are
instructions that perform the check. The information is there, but
with a sufficiently clever compiler -- the sort of implementation I
find most interesting -- finding that information could be
impractical, if not intractable.
Difficult maybe; intractable, I doubt. I think this same argument could be
given for eliminating continuations from Scheme as they create restrictions on
implementation methodologies. There is almost always a tradeoff between
graeter functionality and implementation simplicity. I, for one, think that
the functionality gained by adding ACCEPTS? justifies its complexity. To
convince me otherwise I am afraid you are going to have to be more specific
about why a good compiler gets screwed by accepts. It seems to me that a good
compiler should only pay a cost for ACCEPTS? when it is used (as Jinx has
stated). Isn't this the ideal characterization of a feature? It only costs
the user when they use it.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂23-Aug-89 1102 cph@zurich.ai.mit.edu Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 11:02:35 PDT
Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA05337; Wed, 23 Aug 89 13:24:31 EDT
Received: from localhost by zurich.ai.mit.edu; Wed, 23 Aug 89 13:21:17 edt
Date: Wed, 23 Aug 89 13:21:17 edt
From: cph@zurich.ai.mit.edu (Chris Hanson)
Message-Id: <8908231721.AA07769@zurich.ai.mit.edu>
To: dyb@iuvax.cs.indiana.edu
Cc: rrrs-authors@life.ai.mit.edu
In-Reply-To: R. Kent Dybvig's message of Wed, 23 Aug 89 11:27:42 -0500 <8908231627.AA04605@life.ai.mit.edu>
Subject: Multiple values for R4RS.
Date: Wed, 23 Aug 89 11:27:42 -0500
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
Your argument seems to be that ACCEPTS? is an ill-defined concept ...
My argument is that "accepts?" is virtually meaningless, since it is
a superficial property of the outermost level of the procedure, and there
is no way to extend it further in. If "accepts?" returns #t, so what?
(Here is yet another chapter in the war between the theoreticians and
the engineers.)
Because the proposed semantics of `accepts?' does not return the
"correct" answer 100% of the time, Kent is unwilling to accept it.
Indeed, it is not possible to determine the "correct" answer because
of the halting problem. Yet at the same time, the proposed semantics
is sufficient to solve what Jinx sees as a real problem.
My summary of these arguments is that Kent is rejecting `accepts?'
because it doesn't satisfy a specification which is known to be
impossible to satisfy. I believe this is an unreasonable position,
and we should move on to a more substantive argument. I've heard two
of these:
1. `accepts?' is not very useful. (I agree with Jinx, having used MIT
Scheme's version of this predicate for about a year or so. In
practice, I find that the counterexamples Kent has presented are not
too common.)
2. `accepts?' places an unreasonable burden on the implementor. (I
concede that this -might- be true, but that is a judgment of the
usefulness of `accepts?' as well as its implementation cost.)
∂23-Aug-89 1104 KMP@stony-brook.scrc.symbolics.com Re: Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 11:03:15 PDT
Received: from STONY-BROOK.SCRC.Symbolics.COM by life.ai.mit.edu (4.1/AI-4.10) id AA05149; Wed, 23 Aug 89 13:12:44 EDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 645502; 22 Aug 89 15:12:28 EDT
Date: Tue, 22 Aug 89 15:12 EDT
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Subject: Re: Multiple values for R4RS.
To: ramsdell@linus.mitre.org
Cc: rrrs-authors@life.ai.mit.edu, KMP@stony-brook.scrc.symbolics.com
In-Reply-To: <8908221800.AA08733@huxley.mitre.org>
Message-Id: <19890822191226.5.KMP@BOBOLINK.SCRC.Symbolics.COM>
[1] Do you think VALUES and APPLY-VALUES as defined are controversial?
Yes.
[2] Do you think VALUES and APPLY-VALUES as defined reflect existing
practice?
Yes.
[3] Do you think VALUES and APPLY-VALUES as defined prohibit the
future inclusion of ACCEPTS? or some other proposal to deal with
incompatiable arities?
No, though this seems somewhat irrelevant.
[4] Do you believe VALUES and APPLY-VALUES should be excluded from
Scheme solely because there is no agreement on how to deal with
incompatiable arities?
No.
For what it's worth, I would not endorse the inclusion of VALUES and
APPLY-VALUES as proposed. Here are my suggestions for correcting it:
I would invert the order of arguments. I think this will feel more
natural. APPLY, normal function call, MAP, etc. all work this way.
If you cannot bring yourself to change the order, you should definitely
remove the morpheme `APPLY' to avoid confusion with argument conventions
for the APPLY function. Programmers are likely to model the
values-yielding argument to APPLY-VALUES as a generalized variant of the
list-to-spread last argument to APPLY, and then to wonder why the two
functions take their `other' argument in opposite places.
In fact, I think this function is more closely related to
CALL-WITH-CURRENT-CONTINUATION than to APPLY, and that the naming should
reflect that. I think a name like CALL-WITH-RESULTING-VALUES (or just
CALL-WITH-VALUES, though that's less descriptive) would be better.
In effect, what this operator does is to splice a new function into the
continuation chain. As such, something like INTERPOSE-CONTINUATION or
ENCAPSULATE-CURRENT-CONTINUATION (well, not quite) or
COMPOSE-CURRENT-CONTINUATION (my personal favorite, for `symmetry' with
T's COMPOSE) would also be appropriate.
RECEIVE-VALUES is clearly better than APPLY-VALUES in my mind, but it
still leaves you feeling like it should be a special form that magically
picks up values resulting from the second form, rather than something
which takes a normal functional argument. That's the main reason why I
think something with the morpheme `CONTINUATION' in it would be best.
Although these are syntactic rather than semantic issues, I consider
them important to get right. But modulo the syntax stuff, I strongly
favor the introduction of the proposed level of functionality into R4RS.
By the way, while I'm at it, I don't much like the name VALUES because
it looks yucky for the 1-argument case. Since RETURN is problematic, I
think I would prefer YIELD over VALUES. But I can live with either if
it comes to it.
Also, regarding ACCEPTS?, just so I'm on the record about it, I think a
predicate that took a continuation (or even an arbitrary function) and
an integer and told you if that number of arguments was suitable. I
think the name ACCEPTS? is too short and too general for so specific a
purpose. I would rather a longer, less generic sounding name. But I
have no conflict with the idea of this kind of functionality.
∂23-Aug-89 1104 mkatz@sesame.stanford.edu multiple values
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 11:04:26 PDT
Received: from sesame.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA05385; Wed, 23 Aug 89 13:28:16 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA00373; Wed, 23 Aug 89 10:26:39 PDT
Date: Wed, 23 Aug 89 10:26:39 PDT
From: mkatz@sesame.stanford.edu (Morris Katz)
Message-Id: <8908231726.AA00373@sesame.Stanford.EDU>
To: dyb@iuvax.cs.indiana.edu
Cc: jinx%hpesogg@sde.hp.com, rrrs-authors@life.ai.mit.edu
In-Reply-To: R. Kent Dybvig's message of Wed, 23 Aug 89 10:41:22 -0500 <8908231540.AA04104@life.ai.mit.edu>
Subject: multiple values
Date: Wed, 23 Aug 89 10:41:22 -0500
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
Note that I'm not asking for a requirement that "(values e)" be
distinct from "e", only that we not require that "(values e)" be
the same as "e". So it doesn't rule out an implementation that
automatically truncates multiple values.
I must be missing something. How does the requirement that "(values e)" and
"e" be the same rule out an implementation the automatically truncates?
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂23-Aug-89 1105 mkatz@sesame.stanford.edu multiple values
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 11:04:49 PDT
Received: from sesame.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA05301; Wed, 23 Aug 89 13:22:30 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA00363; Wed, 23 Aug 89 10:21:04 PDT
Date: Wed, 23 Aug 89 10:21:04 PDT
From: mkatz@sesame.stanford.edu (Morris Katz)
Message-Id: <8908231721.AA00363@sesame.Stanford.EDU>
To: will@cs.uoregon.edu
Cc: rrrs-authors@life.ai.mit.edu
In-Reply-To: will@cs.uoregon.edu's message of Tue, 22 Aug 89 18:07:02 PDT <8908230107.AA29487@spencer.cs.uoregon.edu>
Subject: multiple values
Date: Tue, 22 Aug 89 18:07:02 PDT
From: will@cs.uoregon.edu
Passing an incorrect number of arguments to a procedure isn't required to
signal an error, so procedures don't have to check it.
You are correct. I forgot that arity mismatches don't necessarily signal an
error.
Also, why should
the run-time representation of (lambda args #t) include any bits that
indicate the number of arguments it expects?
Assuming that an implementation does put in checks for the wrong number of
args, then, at least in theory, one could parse the code to find the arity
information. This might be a pain in the butt; but, at least in theory, it is
possible. In those cases where the code does not need to check arity because
it was determined not to be necessary at compile time, the answer to an
ACCEPTS? query should also be decidable at compile time. (I wasn't suggesting
this implementation, but only pointing out that an implementation exists which
has essentially zero runtime cost when ACCEPTS? is not used.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂23-Aug-89 1118 mkatz@sesame.stanford.edu Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 11:14:26 PDT
Received: from sesame.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA05552; Wed, 23 Aug 89 13:37:22 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA00404; Wed, 23 Aug 89 10:36:16 PDT
Date: Wed, 23 Aug 89 10:36:16 PDT
From: mkatz@sesame.stanford.edu (Morris Katz)
Message-Id: <8908231736.AA00404@sesame.Stanford.EDU>
To: dyb@iuvax.cs.indiana.edu
Cc: jinx%hpesogg@sde.hp.com, rrrs-authors@life.ai.mit.edu
In-Reply-To: R. Kent Dybvig's message of Tue, 22 Aug 89 22:15:25 -0500 <8908230314.AA07736@life.ai.mit.edu>
Subject: Multiple values for R4RS.
Date: Tue, 22 Aug 89 22:15:25 -0500
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
If we decide to add "accepts?" to the language, we would have to say
that an implementation is free to return #t if it cannot determine
whether or not a given number of arguments is accepted by a given
procedure. An implementation might even define "accepts?" as:
(lambda (procedure arity) #t)
This may seem to water down the predicate, but it only makes explicit
that which must already be true.
Please explain in what cases you believe ACCEPTS? is inherently undecidable.
The above message implies there are such cases, but they are not obvious to me.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂23-Aug-89 1118 @relay.cs.net,@tektronix.tek.com:adams@tekchips.labs.tek.com Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 11:18:14 PDT
Received: from MIT.EDU (MIT.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA05622; Wed, 23 Aug 89 13:44:22 EDT
Received: from RELAY.CS.NET by MIT.EDU with SMTP
id AA03922; Wed, 23 Aug 89 13:44:11 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa02594; 23 Aug 89 13:44 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
id AA22985; Wed, 23 Aug 89 10:46:22 PDT
Received: by tekirl.labs.tek.com (5.51/7.1)
id AA21911; Wed, 23 Aug 89 10:44:15 PDT
Received: by tekchips.LABS.TEK.COM (5.51/6.24)
id AA00958; Wed, 23 Aug 89 10:46:45 PDT
Date: Wed, 23 Aug 89 10:46:45 PDT
From: Norman Adams <adams%tekchips.labs.tek.com@relay.cs.net>
Message-Id: <8908231746.AA00958@tekchips.LABS.TEK.COM>
To: jinx%hpesogg@sde.hp.com
Cc: rrrs-authors%life.ai.mit.edu@relay.cs.net
In-Reply-To: "Guillermo J. Rozas"'s message of Tue, 22 Aug 89 23:12:31 pdt <8908230613.AA04990@sde.hp.com>
Subject: Multiple values for R4RS.
I PERSONALLY find multiple values useless (other people
obviously disagree) if they don't give me the capability that I want.
When someone on this list argues for a change or addition to the
report, I assume they are implicitly asserting that they think such a
change or addition would be for the greater good, and not just to
satisfy some idiosyncrasy.
Identifying something as personal, tends to cut off discussion,
because, after all, you are entitled to your own personal opinion. If
you want to change your position on a proposal, I would prefer that
you do so explicitly.
-Norman
∂23-Aug-89 1126 jar@zurich.ai.mit.edu Just add WITH-VALUES and VALUES.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 11:25:59 PDT
Received: from zurich.ai.mit.edu ([18.43.0.158]) by life.ai.mit.edu (4.1/AI-4.10) id AA05623; Wed, 23 Aug 89 13:44:45 EDT
Received: from localhost by zurich.ai.mit.edu; Wed, 23 Aug 89 13:41:29 edt
Date: Wed, 23 Aug 89 13:41:29 edt
From: jar@zurich.ai.mit.edu (Jonathan Rees)
Message-Id: <8908231741.AA00810@zurich.ai.mit.edu>
To: ramsdell@linus.mitre.org
Cc: rrrs-authors@life.ai.mit.edu
In-Reply-To: ramsdell@linus.mitre.org's message of Wed, 23 Aug 89 07:33:02 EDT <8908231133.AA09643@huxley.mitre.org>
Subject: Just add WITH-VALUES and VALUES.
From: ramsdell@linus.mitre.org
Date: Wed, 23 Aug 89 07:33:02 EDT
As for the politics, consider this proposal as the best opportunity
for a compromise. We ask Kent Dybvig to accept the critical
property that (VALUES E) is always equivalent to E and we ask
Guillermo Rozas to accept no agreement can currently be reached
about an arity checking procedure. Please do not hold WITH-VALUES
and VALUES hostage for they really do represent existing practice,
and many programmers use these procedures. The art of politics is
compromise. What say we give it a try?
I agree. I don't see why every language change has to be a matter of
life and death. These questions are just not so important that the
discussions have to raise so much animosity. It's very depressing to
see so little interest in compromise. Why can't y'all just relax a
little?
∂23-Aug-89 1126 jar@zurich.ai.mit.edu Just add WITH-VALUES and VALUES.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 11:25:56 PDT
Received: from zurich.ai.mit.edu ([18.43.0.158]) by life.ai.mit.edu (4.1/AI-4.10) id AA05683; Wed, 23 Aug 89 13:55:07 EDT
Received: from localhost by zurich.ai.mit.edu; Wed, 23 Aug 89 13:51:53 edt
Date: Wed, 23 Aug 89 13:51:53 edt
From: jar@zurich.ai.mit.edu (Jonathan Rees)
Message-Id: <8908231751.AA00815@zurich.ai.mit.edu>
To: ramsdell@linus.mitre.org
Cc: rrrs-authors@life.ai.mit.edu
In-Reply-To: ramsdell@linus.mitre.org's message of Wed, 23 Aug 89 07:33:02 EDT <8908231133.AA09643@huxley.mitre.org>
Subject: Just add WITH-VALUES and VALUES.
I like the brevity of your proposal, but the proposal should
explicitly say something about what the arity of implicit
continuations (into argument positions for calls, test position of if,
etc.) is. I.e. whether (list (foo)) is equivalent to
(list (with-values foo (lambda (x) x)))
or
(list (with-values foo (lambda (x . ignore) x)))
or something else. As I remember, the near-consensus at Snowbird was
for the second. (That was also the near-consensus at the MIT meeting
of 1987 (?), except that I disagreed; I changed my position later when
I saw that I was outnumbered and when I could understand the semantics
of the other position better. Now I don't much care, I just would
like to see multiple values in some form.)
As long as I'm babbling, my problem with ACCEPTS? or
PROCEDURE-ACCEPTS? is that there is no inverse for it -- no general
way to construct a procedure that can advertise how many arguments it
would like to accept. In particular, it makes invalid Scheme's
currently useful eta-expansion rule: if x is a procedure, then x can
be replaced by (lambda args (apply x args)) [modulo EQ?]. We could
recover some kind of eta rule if we had some way to associate an
ACCEPTS? "method" with a procedure, e.g. maybe (ACCEPTING proc1 proc2)
would return a procedure p that behaved the same as proc1 except that
(ACCEPTS? p n) would return the value returned by (proc2 n).
(You can do this kind of thing in T, which has a crude analogue of
ACCEPTS?.) Then we would have x equivalent to
(accepting (lambda args (apply x args)) (lambda (n) (accepts? x n))).
I'm not proposing ACCEPTING, and I'm not saying that I would veto any
proposal that has ACCEPTS? in it.
∂23-Aug-89 1134 @relay.cs.net,@tektronix.tek.com:adams@tekchips.labs.tek.com Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 11:34:45 PDT
Received: from MIT.EDU (MIT.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA06023; Wed, 23 Aug 89 14:13:27 EDT
Received: from RELAY.CS.NET by MIT.EDU with SMTP
id AA03968; Wed, 23 Aug 89 14:13:14 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa04046; 23 Aug 89 14:12 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
id AA23836; Wed, 23 Aug 89 11:14:47 PDT
Received: by tekirl.labs.tek.com (5.51/7.1)
id AA22493; Wed, 23 Aug 89 11:12:40 PDT
Received: by tekchips.LABS.TEK.COM (5.51/6.24)
id AA01183; Wed, 23 Aug 89 11:15:10 PDT
Date: Wed, 23 Aug 89 11:15:10 PDT
From: Norman Adams <adams%tekchips.labs.tek.com@relay.cs.net>
Message-Id: <8908231815.AA01183@tekchips.LABS.TEK.COM>
To: jinx%hpesogg@sde.hp.com
Cc: dyb@iuvax.cs.indiana.edu, rrrs-authors%life.ai.mit.edu@relay.cs.net
In-Reply-To: "Guillermo J. Rozas"'s message of Tue, 22 Aug 89 23:12:31 pdt <8908230613.AA04990@sde.hp.com>
Subject: Multiple values for R4RS.
From: Kent
* let's add "accepts?" and remove the requirement that Scheme
be case insensitive.
From: Jinx
Again, you are being random. ..
You are ignoring Kent's point.
Using the orginal ground rules from Brandeis -- I don't know what the
ground rules are now -- if everyone wanted A and B, and not everyone
wanted C, then A and B would go in the report and those who wanted C
could have it in their implementations. You have taken the tactic of
getting C in the report by refusing to agree to A and B, but offering
to agree on A, B, and C together. You claim that having A and B
imposes something on you while trying to impose C on everyone else.
So now Kent is making similar offers about those C which he cares
about.
-Norman
∂23-Aug-89 1200 jinx@hpesogg.hp.com Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 12:00:18 PDT
Received: from sde.hp.com (hp-sde.sde.hp.com) by life.ai.mit.edu (4.1/AI-4.10) id AA06416; Wed, 23 Aug 89 14:42:49 EDT
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA26812; Wed, 23 Aug 89 11:41:43 pdt
Message-Id: <8908231841.AA26812@sde.hp.com>
Received: by hpesogg; Wed, 23 Aug 89 11:41:01 pdt
Date: Wed, 23 Aug 89 11:41:01 pdt
From: Guillermo J. Rozas <jinx@hpesogg.hp.com>
To: adams@tekchips.labs.tek.com
Cc: dyb@iuvax.cs.indiana.edu, rrrs-authors@life.ai.mit.edu
In-Reply-To: Norman Adams's message of Wed, 23 Aug 89 11:15:10 PDT <8908231815.AA01183@tekchips.LABS.TEK.COM>
Subject: Multiple values for R4RS.
Reply-To: jinx%hpesogg@sde.hp.com
You are ignoring Kent's point.
Using the orginal ground rules from Brandeis -- I don't know what the
ground rules are now -- if everyone wanted A and B, and not everyone
wanted C, then A and B would go in the report and those who wanted C
could have it in their implementations. You have taken the tactic of
getting C in the report by refusing to agree to A and B, but offering
to agree on A, B, and C together. You claim that having A and B
imposes something on you while trying to impose C on everyone else.
So now Kent is making similar offers about those C which he cares
about.
You are ignoring my position. I DON'T WANT multiple values UNLESS I
can truncate values conveniently. That does not mean that I require
the default be to truncate values, just that it be possible for me to
do so. Otherwise I personally find no use for multiple values, and
would rather not have them in the language at all.
∂23-Aug-89 1200 jinx@hpesogg.hp.com multiple values
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 12:00:33 PDT
Received: from sde.hp.com (hp-sde.sde.hp.com) by life.ai.mit.edu (4.1/AI-4.10) id AA06480; Wed, 23 Aug 89 14:45:08 EDT
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA26880; Wed, 23 Aug 89 11:44:50 pdt
Message-Id: <8908231844.AA26880@sde.hp.com>
Received: by hpesogg; Wed, 23 Aug 89 11:44:08 pdt
Date: Wed, 23 Aug 89 11:44:08 pdt
From: Guillermo J. Rozas <jinx@hpesogg.hp.com>
To: dyb@iuvax.cs.indiana.edu
Cc: rrrs-authors@life.ai.mit.edu
In-Reply-To: R. Kent Dybvig's message of Wed, 23 Aug 89 10:41:22 -0500 <8908231540.AA04104@life.ai.mit.edu>
Subject: multiple values
Reply-To: jinx%hpesogg@sde.hp.com
As an implementor, I would like to signal an error whenever someone
attempts to return (values ...) to a context where multiple values
aren't expected, or something other than (values ...) to a context
expecting multiple values. Requiring "(values e)" to be the same as
"e" makes it impossible to do this. As you pointed out in your note,
this won't affect anyone who doesn't like this behavior, since they
can always create their own versions of "values" and "with-values"
that circumvent the error checks.
Why do you consider (values <single expression>) to be returning
multiple values? It's very clearly returning one.
Your argument seems very similar to trying to distinguish between
(f x)
and
(apply f (list x))
To be consistent, you should want us to categorize procedures
according to whether they can be APPLY'ed (sic), and only allow
APPLY'able (sic) procedures to be APPLY'ed. Otherwise the
implementation should be allowed to signal an error.
∂23-Aug-89 1201 jinx@hpesogg.hp.com Just add WITH-VALUES and VALUES.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 12:01:20 PDT
Received: from sde.hp.com (hp-sde.sde.hp.com) by life.ai.mit.edu (4.1/AI-4.10) id AA06361; Wed, 23 Aug 89 14:39:13 EDT
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA26758; Wed, 23 Aug 89 11:38:55 pdt
Message-Id: <8908231838.AA26758@sde.hp.com>
Received: by hpesogg; Wed, 23 Aug 89 11:38:15 pdt
Date: Wed, 23 Aug 89 11:38:15 pdt
From: Guillermo J. Rozas <jinx@hpesogg.hp.com>
To: ramsdell@linus.mitre.org
Cc: rrrs-authors@life.ai.mit.edu, ramsdell@linus.mitre.org
In-Reply-To: ramsdell@linus.mitre.org's message of Wed, 23 Aug 89 07:33:02 EDT <8908231133.AA09643@huxley.mitre.org>
Subject: Just add WITH-VALUES and VALUES.
Reply-To: jinx%hpesogg@sde.hp.com
As for the politics, consider this proposal as the best oportunity for
a compromise. We ask Kent Dybvig to accept the critical property that
(VALUES E) is always equivalent to E and we ask Guillermo Rozas to
accept no agreement can currently be reached about an arity checking
procedure. Please do not hold WITH-VALUES and VALUES hostage for they
really do represent existing practice, and many programmers use these
procedures. The art of politics is compromise. What say we give it a try?
In a compromise everyone gives in a little. I don't see you doing
that.
The semantics that I want is that extra values are truncated when
returned to implicit continuations. As a compromise, I accept strict
semantics as long as ACCEPTS? is provided. I'm trying to compromise,
you are trying to have me surrender.
∂23-Aug-89 1203 jinx@hpesogg.hp.com Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 12:02:51 PDT
Received: from sde.hp.com (hp-sde.sde.hp.com) by life.ai.mit.edu (4.1/AI-4.10) id AA06596; Wed, 23 Aug 89 14:50:34 EDT
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA27012; Wed, 23 Aug 89 11:50:19 pdt
Message-Id: <8908231850.AA27012@sde.hp.com>
Received: by hpesogg; Wed, 23 Aug 89 11:49:37 pdt
Date: Wed, 23 Aug 89 11:49:37 pdt
From: Guillermo J. Rozas <jinx@hpesogg.hp.com>
To: adams@tekchips.labs.tek.com
Cc: rrrs-authors@life.ai.mit.edu
In-Reply-To: Norman Adams's message of Wed, 23 Aug 89 10:46:45 PDT <8908231746.AA00958@tekchips.LABS.TEK.COM>
Subject: Multiple values for R4RS.
Reply-To: jinx%hpesogg@sde.hp.com
When someone on this list argues for a change or addition to the
report, I assume they are implicitly asserting that they think such a
change or addition would be for the greater good, and not just to
satisfy some idiosyncrasy.
Excuse me, but over half the arguments on this list are based on
aesthetics. Perhaps I'm just more honest because I remind everyone
that it is exactly what I'm doing.
∂23-Aug-89 1235 @relay.cs.net,@gateway.think.com:gls@THINK.COM Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 12:35:45 PDT
Received: from MIT.EDU (MIT.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA06795; Wed, 23 Aug 89 15:04:44 EDT
Received: from RELAY.CS.NET by MIT.EDU with SMTP
id AA04040; Wed, 23 Aug 89 15:04:33 EDT
Received: from gateway.think.com by RELAY.CS.NET id aa06741; 23 Aug 89 15:04 EDT
Received: from fafnir.think.com by Think.COM; Wed, 23 Aug 89 15:04:52 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Wed, 23 Aug 89 15:02:18 EDT
Received: by verdi.think.com; Wed, 23 Aug 89 14:28:00 EDT
Date: Wed, 23 Aug 89 14:28:00 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8908231828.AA13190@verdi.think.com>
To: mkatz%sesame.stanford.edu@relay.cs.net
Cc: adams%tekchips.labs.tek.com@relay.cs.net, jinx%hpesogg@sde.hp.com,
ramsdell%linus.mitre.org@relay.cs.net,
rrrs-authors%life.ai.mit.edu@relay.cs.net
In-Reply-To: Morris Katz's message of Tue, 22 Aug 89 15:34:50 PDT <8908222234.AA00236@sesame.Stanford.EDU>
Subject: Multiple values for R4RS.
Date: Tue, 22 Aug 89 15:34:50 PDT
From: Morris Katz <mkatz%sesame.stanford.edu@relay.cs.net>
Date: Tue, 22 Aug 89 14:15:28 PDT
From: Norman Adams <adams%tekchips.labs.tek.com@relay.cs.net>
As an implementor, I would prefer not
to be committed to keeping around arity information for every
procedure.
I can't imagine how one could create an implementation in which the arity
information is not already present in some form for procedures that are passed
as arguments. Similarly, implicit continuations had better know something
about the number of values on which they intend to operate. Retrieving the
arity information may require some bit twiddling, but I suspect that the needed
information is always present in some form.
You could always walk down the machine language code, trying to figure
out which registers or stack slots it is touching in order to fetch arguments.
(This is not a claim of good engineering, just an existence proof.)
--Guy
∂23-Aug-89 1237 @mc.lcs.mit.edu,@gateway.think.com:gls@think.com Numbers
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 12:37:11 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA06989; Wed, 23 Aug 89 15:15:30 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa15740;
23 Aug 89 15:07 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 23 Aug 89 15:06:09 EDT
Received: from Gateway.Think.COM by mintaka.lcs.mit.edu id aa15732;
23 Aug 89 15:04 EDT
Received: from fafnir.think.com by Think.COM; Wed, 23 Aug 89 15:04:58 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Wed, 23 Aug 89 15:02:23 EDT
Received: by verdi.think.com; Wed, 23 Aug 89 14:25:31 EDT
Date: Wed, 23 Aug 89 14:25:31 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8908231825.AA13164@verdi.think.com>
To: bawden.pa@xerox.com
Cc: gls@think.com, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: bawden.pa@xerox.com's message of Tue, 22 Aug 89 14:40 PDT <19890822214016.5.ALAN@ROCKY.parc.xerox.com>
Subject: Numbers
Date: Tue, 22 Aug 89 14:40 PDT
From: bawden.pa@xerox.com
...
Inexact numbers do not necessarily contain a representation of the
precision with which a quantity is known. In the common case where
floating point is used, they most definitely do not. (In the rare case
where interval arithmetic is used, the bounds are known.) Thus in a
floating point implementation of inexact numbers, you cannot represent the
concepts of "within a few microns of 1000 feet" or "within four inches of
three feet". The best you can do is "perhaps 1000 feet" and "about four
feet". The MAX of these two is "perhaps 1000 feet" -- any arguments about
the precision ("within a few microns of 1000 feet" vs. "within four inches
of 1000 feet") are in the province of a numerical analyst to reason about.
Okay, I'll grant that. But I inserted "within a few microns" one for the
sake of lending plausibility to my physical metaphor--possibly a rhetorical
mistake. My code example clearly involves "exactly 1000 feet".
What I was -actually- claiming was that the MAX of "exactly 1000 feet" and
"about four feet" is "perhaps 1000 feet". (In an implementation that used
interval arithmetic, I could indeed compute the MAX of "exactly 1000 feet"
and "within four inches of three feet" and get "exactly 1000 feet", but in
-general-, inexact arithmetic does not have this ability.)
I agree that in *some* cases the best you can do is return an inexact
representation of one's best guess. But sometimes you can tell for sure
that the answer is exact, even if some of the inputs were inexact.
Perhaps a numerical analyst can look at my program and tell me that for
sure. Perhaps if I am using interval arithmetic my implementation can tell
me that for sure. But if I am using floating point, my implementation can
-never- know that for sure.
Here is where the cart may be before the horse. I'll let you inspect the
*types* of the arguments up front in any case. Are you then deciding a
priori to use floating-point to represent the result only on the basis of
the argument types, without regard to the values involved? Or do you
entertain the possibility that the type (or representation) of the result
may depend on the specific values of the arguments? I am arguing for the
latter.
In other words, I deny that the inexactness contagion used for + and * is
appropriate for MAX and MIN. Why is 549755813888.0 the closest we can
come? Only because we have made an arbitrary decision to cast the result
into a representation that reflects the inexactness of the least exact
input, regardless of whether that amount of inexactness in fact had
anything to do with the result computed.
It was not an "arbitrary decision" at all. 549755813888.0 is closest
because we only have 23-bit floating point to represent inexact numbers,
and the answer must be inexact. Its the best we can do. If we return an
exact number we are potentially returning an -INCORRECT- result. We don't
know the answer exactly, so we cannot return an exact number.
Presumably when you say "perhaps 1000 feet" you mean something different
from "perhaps 4 feet", or otherwise you would not bother; you would have a
single inexact number called "perhaps". There is some level of confidence
that leads you to say "perhaps 100" in preference to any other inexact
result. Am I to regard an inexact number as a probability distribution
(whose shape I may know nothing about)? An interval is one kind of
probability distribution. Maybe I am to understand it as more like a
Gaussian, which tails off but is never zero anywhere. Maybe in that case I
agree that (max 4.0 1000) is "perhaps 1000". But then I am not sure I
believe the underlying model. This is not a fair argument, of course,
because I am knocking down my own straw man. But it illustrates the sort
of model for inexact numbers that I seek. I find the "perhaps" model a bit
*too* vague.
WHat can be said about the level of confidence that leads one to
say "perhaps 1000" instead of merely "perhaps"?
--Guy
∂23-Aug-89 1238 jinx@hpesogg.hp.com Just add WITH-VALUES and VALUES.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 12:38:33 PDT
Received: from sde.hp.com (hp-sde.sde.hp.com) by life.ai.mit.edu (4.1/AI-4.10) id AA06929; Wed, 23 Aug 89 15:13:04 EDT
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA27595; Wed, 23 Aug 89 12:12:31 pdt
Message-Id: <8908231912.AA27595@sde.hp.com>
Received: by hpesogg; Wed, 23 Aug 89 12:11:50 pdt
Date: Wed, 23 Aug 89 12:11:50 pdt
From: Guillermo J. Rozas <jinx@hpesogg.hp.com>
To: jar@zurich.ai.mit.edu
Cc: ramsdell@linus.mitre.org, rrrs-authors@life.ai.mit.edu
In-Reply-To: Jonathan Rees's message of Wed, 23 Aug 89 13:51:53 edt <8908231751.AA00815@zurich.ai.mit.edu>
Subject: Just add WITH-VALUES and VALUES.
Reply-To: jinx%hpesogg@sde.hp.com
As long as I'm babbling, my problem with ACCEPTS? or
PROCEDURE-ACCEPTS? is that there is no inverse for it -- no general
way to construct a procedure that can advertise how many arguments it
would like to accept. In particular, it makes invalid Scheme's
currently useful eta-expansion rule: if x is a procedure, then x can
be replaced by (lambda args (apply x args)) [modulo EQ?]. We could
recover some kind of eta rule if we had some way to associate an
ACCEPTS? "method" with a procedure, e.g. maybe (ACCEPTING proc1 proc2)
would return a procedure p that behaved the same as proc1 except that
(ACCEPTS? p n) would return the value returned by (proc2 n).
(You can do this kind of thing in T, which has a crude analogue of
ACCEPTS?.) Then we would have x equivalent to
(accepting (lambda args (apply x args)) (lambda (n) (accepts? x n))).
I'm not proposing ACCEPTING, and I'm not saying that I would veto any
proposal that has ACCEPTS? in it.
I've been considering adding a similar procedure to MIT Scheme for a
while, but along slightly different lines:
(restrict-arity proc1 proc2) -> proc3
where proc3 has the same arity signature that proc2 has, yet invokes
proc1 instead. It must also be the case that
"for all n s.t. (accepts? proc2 n) -> #t, (accepts? proc1 n) -> #t"
otherwise restrict-arity should error.
The "eta" rule would be obtained by doing
(restrict-arity (lambda args (apply x args)) x)
Unfortunately, due to the lack of an optional argument mechanism in
the standard, it would be hard to "copy" things like WRITE-CHAR, but
hopefully (perhaps I'm being naive) this will be resolved
independently.
MIT Scheme currently has a restricted form of this in the following
(provided for a different reason)
(coerce-to-compiled proc1 n) -> proc2
proc2 expects exactly n arguments.
The original intent for this would be that map, or for-each, or
similar things would do their arguments checking once by using
coerce-to-compiled, and then invoke the resulting procedure directly
without any further arity checks.
∂23-Aug-89 1407 gls@think.com theology; MAX and MIN
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 14:06:44 PDT
Received: from Think.COM (Gateway.Think.COM) by life.ai.mit.edu (4.1/AI-4.10) id AA06580; Wed, 23 Aug 89 14:49:47 EDT
Received: from fafnir.think.com by Think.COM; Wed, 23 Aug 89 14:50:20 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Wed, 23 Aug 89 14:35:24 EDT
Received: by verdi.think.com; Wed, 23 Aug 89 14:34:50 EDT
Date: Wed, 23 Aug 89 14:34:50 EDT
From: gls@think.com (Guy Steele)
Message-Id: <8908231834.AA13278@verdi.think.com>
To: will@cs.uoregon.edu
Cc: rrrs-authors@life.ai.mit.edu
In-Reply-To: will@cs.uoregon.edu's message of Tue, 22 Aug 89 18:08:24 PDT <8908230108.AA29492@spencer.cs.uoregon.edu>
Subject: theology; MAX and MIN
Date: Tue, 22 Aug 89 18:08:24 PDT
From: will@cs.uoregon.edu
Guy Steele Jr:
Theologically or politically speaking, under the first view inexact numbers
strive to obey laws acknowledged to be perfect, but to a greater or lesser
degree are each in a state of sin. Under the second view they are all
model citizens, adhering perfectly to their own laws which, however, are
acknowledged not to be ideal but merely the best one can do in this
imperfect and finite world.
In the imperfect world I live in, the supremum implied by the phrase
"the best one can do" is even less likely to exist than in the world of
computer arithmetic.
Touche'. Make that "merely a pretty good thing one can do...".
Theologically speaking, Guy's new proposal has the same problem as his old
proposal: It introduces two new demons to undermine a user's faith in
exact numbers. Only the names have changed: now the demons are called
LARGEST and SMALLEST. The damage done by these two procedures won't be
ameliorated by having exactness-preserving SUP and INF as well. For
simplicity, I say that if MAX and MIN, by whatever names, are going to be
exceptions to the perfect rules of exactness, then let's just acknowledge
them as exceptions and to hell, theologically speaking, with the sinfully
striving exactness-preserving versions.
Hm. Mayhaps my metaphor hath become a petard.
I don't see why faith in the *exact* has been undermined, but only faith
in the *inexact* (which was probably misplaced anyway). I think we all
agree that SUP and MAX/LARGEST would agree on exact inputs. I think that
when you speak of "exactness-preserving" you mean "inexactness-preserving",
and similarly "perfect rules of exactness" => "perfect rules of
inexactness" which is then seen to be a contradiction in terms.
--Guy "I Haven't Had So Much Fun While Trying to Be Serious in Years" Steele
∂23-Aug-89 1407 jinx@hpesogg.hp.com Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 14:07:44 PDT
Received: from sde.hp.com (hp-sde.sde.hp.com) by life.ai.mit.edu (4.1/AI-4.10) id AA06574; Wed, 23 Aug 89 14:49:33 EDT
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA26969; Wed, 23 Aug 89 11:49:12 pdt
Message-Id: <8908231849.AA26969@sde.hp.com>
Received: by hpesogg; Wed, 23 Aug 89 11:48:30 pdt
Date: Wed, 23 Aug 89 11:48:30 pdt
From: Guillermo J. Rozas <jinx@hpesogg.hp.com>
To: dyb@iuvax.cs.indiana.edu
Cc: rrrs-authors@life.ai.mit.edu
In-Reply-To: R. Kent Dybvig's message of Wed, 23 Aug 89 11:27:42 -0500 <8908231627.AA04605@life.ai.mit.edu>
Subject: Multiple values for R4RS.
Reply-To: jinx%hpesogg@sde.hp.com
Ah, but I can ask (and (pair? x) (pair? (cdr x))), and if this is #t,
then I can be certain that (cddr x) won't error.
Similarly, I can ask
(and (accepts? p 3) (accepts? cons 3))
I don't see the difference.
Your argument seems to be that ACCEPTS? is an ill-defined concept ...
My argument is that "accepts?" is virtually meaningless, since it is
a superficial property of the outermost level of the procedure, and there
is no way to extend it further in. If "accepts?" returns #t, so what?
It is only meaningless if the implementor or the programmer purposely
decide to make it unusable. I listed an additional constraint that
would make ACCEPTS? valid in the cases that I'm concerned about here.
I don't care whether you chose to write all your code differently and
therefore make it unusable in YOUR code. I want to be able to use it
on implementation provided procedures and on MY procedures, which I'll
carefully write so that it is meaningful.
∂23-Aug-89 1418 ramsdell@linus.mitre.org Amended WITH-VALUES and VALUES.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 14:18:08 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA08065; Wed, 23 Aug 89 17:00:38 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA23412; Wed, 23 Aug 89 15:56:23 EDT
Posted-Date: Wed, 23 Aug 89 15:56:18 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA10022; Wed, 23 Aug 89 15:56:19 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8908231956.AA10022@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Cc: ramsdell@linus.mitre.org
Subject: Amended WITH-VALUES and VALUES.
In-Reply-To: Your message of Wed, 23 Aug 89 11:38:15 -0700.
<8908231838.AA26758@sde.hp.com>
Date: Wed, 23 Aug 89 15:56:18 EDT
>> In a compromise everyone gives in a little. I don't see you doing
>> that.
>>
>> The semantics that I want is that extra values are truncated when
>> returned to implicit continuations. As a compromise, I accept strict
>> semantics as long as ACCEPTS? is provided. I'm trying to compromise,
>> you are trying to have me surrender.
>>
>>
As Jqnathan Rees points out, the proposal should explicitly say
something about what the arity of implicit continuations. My
compromise proposal says nothing about that subject because I thought
it would eliminate the chance of reaching an agreement. I have an
opinion on the subject, but I will not propose it in the interest of
getting multiple values into Scheme. Implementations may explore many
alteratives. With the current proposal, implementation may or may not
ignore extra values returned by a procedure. All it requires is that
the number of arguments generated by the first argument of WITH-VALUES
matches the arity of the second argument of WITH-VALUES, and (values
E) returns E. To make the situation about VALUES clear, I added a note
to that section.
I leave unspecified the behavior of the following code:
(list (values 1 2))
John
------------------------------ Amended WITH-VALUES Proposal.
(values obj ...) essential procedure
Returns 0 or more values to a receiving procedure (See with-values).
(values) => returns zero (no) values
(values 1) => returns a single value, 1
(values 1 'a) => returns two values, 1 and the symbol a
Note: When applied to one argument, values simply returns its argument.
(with-values generator receiver) essential procedure
Returns the result of applying the procedure 'receiver' to the values
produced by calling procedure 'generator' with no arguments. It is an
error if 'receiver' cannot be applied to the number of values returned
by 'generator' or if 'generator' cannot be called with zero arguments.
(with-values
(lambda ()
(values 1 2))
cons) => (1 . 2)
--------------------------------
∂23-Aug-89 1502 dyb@iuvax.cs.indiana.edu Re: Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 15:02:23 PDT
Received: from iuvax.cs.indiana.edu by life.ai.mit.edu (4.1/AI-4.10) id AA08639; Wed, 23 Aug 89 17:46:33 EDT
Message-Id: <8908232146.AA08639@life.ai.mit.edu>
Received: by iuvax.cs.indiana.edu
Date: Wed, 23 Aug 89 16:46:34 -0500
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
To: mkatz@sesame.stanford.edu
Subject: Re: Multiple values for R4RS.
Cc: rrrs-authors@life.ai.mit.edu
> If we decide to add "accepts?" to the language, we would have to say
> that an implementation is free to return #t if it cannot determine
> whether or not a given number of arguments is accepted by a given
> procedure. An implementation might even define "accepts?" as:
>
> (lambda (procedure arity) #t)
>
> This may seem to water down the predicate, but it only makes explicit
> that which must already be true.
>
> Please explain in what cases you believe ACCEPTS? is inherently undecidable.
> The above message implies there are such cases, but they are not obvious to me.
It's all in how you define the technical term "accepts". Does it mean
that the procedure won't signal an error if you pass it the given
number of arguments, or is it a superficial property the procedure
derived from the syntax of the lambda expression from which the
procedure was derived? The latter isn't very interesting, since I can
fool it easily (see the examples in prior notes), and the former is
obviously undecidable. If it is the latter, then in R4RS Scheme,
"accepts?" is decidable. However, we would have to state in the report
that "accepts" doesn't really mean what it sounds like it means, since
the procedure may in reaility reject the given number of arguments.
Kent
∂23-Aug-89 1506 @zermatt.lcs.mit.edu:ziggy@HX.LCS.MIT.EDU RE: RECORDs proposal
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 15:06:21 PDT
Received: from ZERMATT.LCS.MIT.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA08740; Wed, 23 Aug 89 17:52:17 EDT
Received: from RTS-8.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via CHAOS with SMTP id 284438; 23 Aug 89 17:52:09 EDT
Message-Id: <2828901124-3894493@RTS-8>
Sender: ziggy@rts-8.ai.mit.edu
Date: Wed, 23 Aug 89 17:52:04 EDT
From: "Michael R. Blair" <ziggy@hx.lcs.mit.edu>
To: rrrs-authors%life.ai.mit.edu@zermatt.ai.mit.edu
Subject: RE: RECORDs proposal
Not to detract from the Multiple Values Return debate nor the Numbers polemic
(both of which are very informative), but lest we forget about RECORDs, I have
a couple questions. Forgive me if I missed a discussion, the outcome of which
is reflected in the original proposal, but I am concerned that the current
proposal makes it difficult for me to treat the order of slot-names in a
record as irrelevant. First,
> (RECORD-TYPE-SLOT-NAMES rtd)
>
> Returns a list of the symbols naming the slots in members of the type
> represented by rtd. The returned value is EQUAL? to the slot-names
> argument given in the call to MAKE-RECORD-TYPE that created the type
> represented by rtd.
Why stipulate that this be EQUAL? to the original call? Why does it not
suffice for it to be merely SET-EQUAL? (that is, some permutation of the
original slot-names list)?
Is there something technical you can do with the result as specified that you
would not necessarily be able to do with the result of the looser spec? Note
one possible implementation of the looser spec is to do just what you
specified: use the identity permutation.
Why do I ask? I would like to create a rtd by first sorting the slot-names
argument (e.g., by lexicographical order of the slot-names' print names) and
create an rtd with this sorted slot-names list. This is because I want
slot-names to be order-irrelevant.
To that end, I'm not sure I find RECORD-CONSTRUCTOR particularly useful as it
is. To point:
> (RECORD-CONSTRUCTOR rtd)
>
> Returns a procedure for constructing new members of the type represented by
> rtd. The returned procedure accepts exactly as many arguments as there
> were slot-names in the call to MAKE-RECORD-TYPE that created the type
> represented by rtd; these are used, in order, as the initial values of
> those slots in a new record, which is returned by the constructor
> procedure.
My concern is that the generated constructor operates By Order of Arguments,
what CLtL notes is sometimes called a BOA constructor. What I want is a
construction procedure Wherein (arg) ORder is Considered IRrelevent: a
construction WORCIR (Worker? Rather suggests that it does a little more work
than a mere limbless reptile, no?). For example:
I would rather see a constructor procedure that looks more like:
(DEFINE make-mumble (RECORD-CONSTRUCTOR mumble-rtd))
(make-mumble slot-name val slot-name val...)
It should signal an error if I name a slot not in the slot-names of mumble-rtd
It could be an error if I fail to name a slot that IS in the slot-names of
mumble-rtd.
Again, the point being that I want the order of slot names to be irrelevant.
To do otherwise would be to give me something not much more useful than
VECTORs. Thus when I make an instance of some record type, I don't want to
have to order the initial values to match the irrelevantly ordered slot-names.
I would rather provide slot-name/value duples.
For the case where you don't mind observing the irrelevant defined order
(e.g., to avoid naming all the slots) you could use a RIGID-RECORD-CONSTRUCTOR
which could function as you specified. (RECORD-BOA-CONSTRUCTOR)
Or better yet, I would like a syntax like:
(make-mumble ((slot-name val)(slot-name val)...))
since I imagine object instantiation to be essentially a binding and packaging
operation [make a bunch of bindings, package them into a RECORD, and return
the RECORD], but I wouldn't dare propose that lest you all banish me to the
mythical macro library or condemn me of perpetuating syntax.
Fnord. Not to mention defaulting. Fnord.
~Ziggy
∂23-Aug-89 1513 jinx@hpesogg.hp.com Amended WITH-VALUES and VALUES.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 15:13:12 PDT
Received: from sde.hp.com (hp-sde.sde.hp.com) by life.ai.mit.edu (4.1/AI-4.10) id AA08791; Wed, 23 Aug 89 17:56:30 EDT
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA01098; Wed, 23 Aug 89 14:32:48 pdt
Message-Id: <8908232132.AA01098@sde.hp.com>
Received: by hpesogg; Wed, 23 Aug 89 14:32:06 pdt
Date: Wed, 23 Aug 89 14:32:06 pdt
From: Guillermo J. Rozas <jinx@hpesogg.hp.com>
To: ramsdell@linus.mitre.org
Cc: rrrs-authors@life.ai.mit.edu, ramsdell@linus.mitre.org
In-Reply-To: ramsdell@linus.mitre.org's message of Wed, 23 Aug 89 15:56:18 EDT <8908231956.AA10022@huxley.mitre.org>
Subject: Amended WITH-VALUES and VALUES.
Reply-To: jinx%hpesogg@sde.hp.com
As Jqnathan Rees points out, the proposal should explicitly say
something about what the arity of implicit continuations. My
compromise proposal says nothing about that subject because I thought
it would eliminate the chance of reaching an agreement. I have an
opinion on the subject, but I will not propose it in the interest of
getting multiple values into Scheme. Implementations may explore many
alteratives. With the current proposal, implementation may or may not
ignore extra values returned by a procedure. All it requires is that
the number of arguments generated by the first argument of WITH-VALUES
matches the arity of the second argument of WITH-VALUES, and (values
E) returns E. To make the situation about VALUES clear, I added a note
to that section.
I will accept the proposal if it leaves the arity of implicit
continuations unspecified, and it is explicitely stated.
∂23-Aug-89 1516 @mc.lcs.mit.edu,@life.ai.mit.edu:gls@think.com INF/SUP/MIN/MAX
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 15:15:52 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA08792; Wed, 23 Aug 89 17:56:38 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa10082;
21 Aug 89 12:22 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Aug 89 12:21:41 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa09778;
21 Aug 89 11:54 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA01440; Mon, 21 Aug 89 11:54:38 EDT
Received: from Think.COM ([131.239.2.1]) by zurich.ai.mit.edu; Mon, 21 Aug 89 11:51:20 edt
Received: from fafnir.think.com by Think.COM; Mon, 21 Aug 89 11:53:56 EDT
Received: from verdi.think.com by fafnir.think.com; Mon, 21 Aug 89 11:51:20 EDT
Received: by verdi.think.com; Mon, 21 Aug 89 11:51:09 EDT
Date: Mon, 21 Aug 89 11:51:09 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8908211551.AA29546@verdi.think.com>
To: jeff%aiai.edinburgh.ac.uk@nsfnet-relay.ac.uk
Cc: gls@think.com, cph@zurich.ai.mit.edu, Alan@reagan.ai.mit.edu,
KMP@stony-brook.scrc.symbolics.com, RRRS-Authors@zurich.ai.mit.edu
In-Reply-To: Jeff Dalton's message of Sun, 30 Jul 89 17:36:25 BST <11536.8907301636@subnode.aiai.ed.ac.uk>
Subject: INF/SUP/MIN/MAX
Date: Sun, 30 Jul 89 17:36:25 BST
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@nsfnet-relay.ac.uk>
>From: Guy Steele <gls@think.com>
> Date: Wed, 26 Jul 89 15:49:33 edt
> From: cph@zurich.ai.mit.edu (Chris Hanson)
>
> [quotes Steele's arguments about Quux-head pennies, etc.]
> I don't buy these arguments: many of them have to do with side
> effects, and since when are there any side effects on numbers? So
> they don't apply.
>
> Granted. "Plus ca change, plus c'est la meme chose", as Sussman and I
> quoted in "The Art of the Interpreter". The more things change, the more
> they remain the same; that is, the notion of object identity may be linked
> to the notion of side effect. And yet, if numbers are not subject to
> side effects, in what sense can we say that 1 = 1, or that 1 /= 2 ?
I think this observation of numeric identity shows that identity can
be linked to side-effects, but also that identity doesn't require this
link. Indeed, I don't find the argument that there's some sort of
implicit potential side-effect involved in asking 1 = 1 very
convincing.
How is it, then, that 1 /= 2? What is there that makes them different?
How is it that "+" can distinguish between them? I find it very
unsatisfying to say of "+" merely that it is primitive, it does it
because that's what it does, and I should stop asking so many silly
questions. The same is true, by the way, of symbols: how is it that
"FOO" is distinguishable from "BAR"?
> I think that when we say 1 = 1, we are temporarily entertaining the
> possibility that the two instances of "1" represent *different* things,
> precisely so that we may then make the assertion that they are the same
> after all.
When I say "Nixon is the author of Six Crises", do this mean I'm
temporarily entertaining the possibliity that someone else wrote it?
Well, perhaps I'm at least entertaining the possibility that the
person I'm speaking to thinks so.
Exactly so.
But what if I say just "Nixon is
Nixon"? It may seem that I must have some possibility in mind that I
am trying to deny. But I don't think it's clear what this possibility
is unless I say something more. For example, I might say: "The person
you call 'Nixon' is the same person I know as 'Nixon', the author of
Six Crises, etc., and not two different people as we had once
supposed."
Again, exactly so. See below.
But it's hard to see how there could be this kind of
confusion about "'1' as defined by Scheme".
Only because "1" is a little more famous than Nixon; it's a matter of
degree rather than principle.
Indeed, it seems to me
that once we agree about what "Nixon" refers to, we can say "Nixon is
Nixon" without necessarily entertaining any possibility that Nixon
isn't Nixon.
So I don't think it's straightforward to conclude that when we
say 1 = 1, etc.
> If one of the 1's were not 1 after all, then things would be
> different, including the truth of the equality. This subjunctive
> hypothesis amounts to a side effect, for we are considering, hypothetically
> and however evanescently, a world altered from our own (whether by SETQ
> or by adding an entry to the head of an a-list).
But is every difference the result of a side-effect? Perhaps we're
just entertaining the possibility that "=" doesn't mean what we
thought it meant or that tokens like "1" refer to something different
each time.
The latter is a possibility, however temporarily it is entertained or
however trivially resolved.
∂23-Aug-89 1519 dyb@iuvax.cs.indiana.edu Re: Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 15:19:48 PDT
Received: from iuvax.cs.indiana.edu by life.ai.mit.edu (4.1/AI-4.10) id AA08887; Wed, 23 Aug 89 18:04:38 EDT
Message-Id: <8908232204.AA08887@life.ai.mit.edu>
Received: by iuvax.cs.indiana.edu
Date: Wed, 23 Aug 89 16:33:43 -0500
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
To: gls@think.com
Subject: Re: Multiple values for R4RS.
Cc: rrrs-authors@life.ai.mit.edu
> You could always walk down the machine language code, trying to figure
> out which registers or stack slots it is touching in order to fetch arguments.
> (This is not a claim of good engineering, just an existence proof.)
> --Guy
Are you assuming that there are explicit references to the registers or
stack slots holding the values? There may in fact be no such
references. Perhaps the code performs some sort of computation to
derive an index into the stack holding the argument and the value of
that computation cannot be determined. Or perhaps the code does not
touch one or more of its arguments explicitly, but leaves them in place
as arguments to another procedure that it calls.
Kent
∂23-Aug-89 1718 dyb@iuvax.cs.indiana.edu Re: multiple values
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 17:17:56 PDT
Received: from iuvax.cs.indiana.edu by life.ai.mit.edu (4.1/AI-4.10) id AA08282; Wed, 23 Aug 89 17:14:45 EDT
Message-Id: <8908232114.AA08282@life.ai.mit.edu>
Received: by iuvax.cs.indiana.edu
Date: Wed, 23 Aug 89 16:15:20 -0500
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
To: rrrs-authors@life.ai.mit.edu
Subject: Re: multiple values
> Note that I'm not asking for a requirement that "(values e)" be
> distinct from "e", only that we not require that "(values e)" be
> the same as "e". So it doesn't rule out an implementation that
> automatically truncates multiple values.
>
> I must be missing something. How does the requirement that "(values e)" and
> "e" be the same rule out an implementation the automatically truncates?
It doesn't! However, among those who want to be allowed to automatically
trucate multiple values, there seems to be an impression that "(values e)"
must be the same as "e" in order for them to to do so. I was merely
pointing out that allowing "(values e)" and "e" to be different does not
preclude their implementations from treating them the same and hence does
not preclude them from implementing automatic truncation.
∂23-Aug-89 1759 halstead@crl.dec.com
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 17:59:05 PDT
Received: from decwrl.dec.com by life.ai.mit.edu (4.1/AI-4.10) id AA10304; Wed, 23 Aug 89 20:42:28 EDT
Received: by decwrl.dec.com; id AA05392; Wed, 23 Aug 89 12:21:43 -0700
Date: Wed, 23 Aug 89 12:21:43 -0700
From: halstead@crl.dec.com
Message-Id: <8908231921.AA05392@decwrl.dec.com>
Received: by crl.crl.dec.com (5.57/Ultrix2.4-C)
id AA10352; Wed, 23 Aug 89 15:20:38 EDT
Apparently-To: <rhh@lcs.mit.edu>
Apparently-To: <rrrs-authors@life.ai.mit.edu>
Cc: halstead@crl.dec.com, rhh@lcs.mit.edu
Subject: multiple return values -- APPLY-OPTIONAL, a modest proposal
Date: Wed, 23 Aug 89 15:18:27 EDT
From: halstead@crl.dec.com
Here's a fresh look at the problem. It strikes me as kind of way-out,
but maybe not too way-out for serious consideration.
We are concerned with having continuations that may accept multiple
arguments (or no arguments!) and having some way to return to a
continuation the number of arguments that it wants. In the simple
case (no ACCEPTS?, exact arity match required), we can write VALUES
as a procedure
(define (values . vals)
(call/cc
(lambda (k) (apply k vals))))
Yes? (The above is intended to be non-controversial.)
The problem arises when we want to add flexibility to the interface
between VALUES and the continuation, e.g. to implement the Common Lisp
"feature" that allows excess values to be discarded if they are not
wanted by the continuation. This is the motivation for having ACCEPTS?.
Let's step back and consider another case where Scheme already allows
for flexibility in the number of arguments passed. We can already
write a procedure like (lambda (a b . rest) ...) that requires 2 or more
arguments, so the callee can express a willingness to be flexible in
the number of arguments passed, within some limits. The proposal to
include ACCEPTS? is motivated by a desire to allow the *caller* some
similar flexibility, by letting it effectively negotiate with the callee
to settle on a number of arguments that the callee will be happy with.
The problem with that, as Kent points out, is that the negotiation is
only skin-deep, and can't take into account restrictions built into
the callee's definition, e.g., in
(lambda (a b . rest)
(if (> (length rest) 2)
(error ...)
(let ((c (car rest))
(d (cadr rest)))
.... c .... d ....)))
where the procedure really only "accepts" either 2, 3, or 4 arguments.
Can we solve this problem by pushing it down a level? Here's a 3/4-baked
proposal to do just that: introduce a new procedure APPLY-OPTIONAL that
is used as (APPLY-OPTIONAL f a1 a2 ... an optional-args). If f cannot
accept at least n arguments, then this "is an" ("signals an"?) error.
If f requires at least m>=n arguments, then m-n additional arguments
are taken off the list of optional-args. When f looks like it can
accept an unbounded number of arguments, I think you have to pass all of
optional-args. (Perhaps this is the Achilles heel of the proposal.)
Now we can write a VALUES that operates as in Common Lisp like this:
(define (values . vals)
(call/cc
(lambda (k)
(apply-optional k vals))))
(or you can vary it to suit your tastes regarding special treatment of
supplying 0 arguments to VALUES, etc.).
I like this idea because it makes the call interface more symmetrical
regarding optional arguments: if the callee gets to specify flexibility
in accepting calls from different kinds of callers, why shouldn't the
callers be able to specify similar flexibility in the callees they will
deal with? I also think this proposal avoids the problems that Kent
has criticized ACCEPTS? for: in this proposal, the code inside the
procedure gets to decide whether it will accept a given set of arguments
-- or it can pass the buck on that decision -- without needing to encode
its criteria in a form that ACCEPTS? can decipher. On the other hand,
some cans of worms are opened: my 2-, 3-, or 4-argument procedure above
would reject a call like (APPLY-OPTIONAL F 1 2 3 '(4 5 6)) even though
there is a way to satisfy F's requirements. To fix this, we need to give
a procedure some hooks so it can tell which of its arguments were optionally
supplied. Urk!
Comments? -Bert Halstead
∂23-Aug-89 1954 @mc.lcs.mit.edu,@life.ai.mit.edu:gls@think.com MIN and MAX (long message)
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 19:53:59 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA10974; Wed, 23 Aug 89 22:31:43 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa11410;
21 Aug 89 14:19 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Aug 89 14:19:48 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa11318;
21 Aug 89 14:12 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02850; Mon, 21 Aug 89 14:12:13 EDT
Received: from life.ai.mit.edu (life.ai.mit.edu) by zurich.ai.mit.edu; Mon, 21 Aug 89 14:08:57 edt
Received: from Think.COM (Gateway.Think.COM) by life.ai.mit.edu (4.1/AI-4.10) id AA02847; Mon, 21 Aug 89 14:12:06 EDT
Received: from fafnir.think.com by Think.COM; Mon, 21 Aug 89 14:09:47 EDT
Received: from verdi.think.com by fafnir.think.com; Mon, 21 Aug 89 14:07:21 EDT
Received: by verdi.think.com; Mon, 21 Aug 89 14:07:11 EDT
Date: Mon, 21 Aug 89 14:07:11 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8908211807.AA01875@verdi.think.com>
To: will@cs.uoregon.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: will@cs.uoregon.edu's message of Mon, 7 Aug 89 16:02:42 PDT <8908072302.AA04327@spencer.cs.uoregon.edu>
Subject: MIN and MAX (long message)
Date: Mon, 7 Aug 89 16:02:42 PDT
From: will@cs.uoregon.edu
Guy Steele Jr:
...every C weenie has the formula
#define max(x,y) ((x) > (y)) ? (x) : (y)
engraved in his little weenie brain. See? MAX really is a conditional.
I'm not much of a C weenie, and I don't have a description of the
proposed (or actual?) ANSI standard, but I think I know enough C to
suspect that Guy didn't mean for us Scheme weenies to take this seriously.
When examined more closely, Guy's example shows that C weenies think more
like me than like Guy. (This doesn't surprise me, unfortunately.)
C is a statically typed language, with very little polymorphism, that
regards ints and floats as different types. (I'm going to speak as
though all the different integer types were collapsed into one type, and
all the different float types into one type.) The two alternatives of
a conditional expression must have the same type, or else be convertible
to the same type using C's conversion rules. If you define max as Guy
suggested and then write max(2.5, 1000) as an expression, then the result
of that expression will be a float (1000.0), not an int.
If you write max(2.5, 1000) in a context that expects an int, then the
floating point 1000.0 will be converted back into an int (1000). (It
isn't wise to regard that conversion as part of the expression's
semantics, because you would then have to believe that max(2, 1000.5)
also evaluates to an int.) Hence max(2.5, 1000) in an int context is
really the equivalent of (INEXACT->EXACT (TRUNCATE (MAX 2.5 1000))) in
Scheme.
So if MAX really is a conditional in C, then (MAX 2.5 1000) ==> 1000.0
is consistent with MAX being a conditional. It seems that Guy's example
actually supports the R3.95RS semantics he was arguing against.
But my point of view is that the MAX operation per se, like other C
operators is *not* polymorphic. They operate only on two ints or
two floats. The type mechanism enforces this requirement by inserting
coercions; the point is that these coercions are outside the control
of the implementation of the operation itself, and therefore not
properly a part of them. In exactly the same way that max(2.5, 1000)
in an int context ends up having a coercion inserted, so the coercion
that converts 1000 to a float is artificially inserted.
∂23-Aug-89 2120 @mc.lcs.mit.edu,@life.ai.mit.edu:bawden.pa@xerox.com Programmer-defined data types
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 21:20:30 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA12551; Thu, 24 Aug 89 00:04:52 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa11727;
21 Aug 89 14:45 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Aug 89 14:44:58 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa11697;
21 Aug 89 14:42 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA03287; Mon, 21 Aug 89 14:42:53 EDT
Received: from Xerox.COM (xerox.com) by zurich.ai.mit.edu; Mon, 21 Aug 89 14:39:20 edt
Received: from Semillon.ms by ArpaGateway.ms ; 21 AUG 89 11:36:45 PDT
Date: Mon, 21 Aug 89 11:34 PDT
From: bawden.pa@xerox.com
Subject: Programmer-defined data types
To: Pavel.pa@xerox.com
Cc: RRRS-Authors@zurich.ai.mit.edu
In-Reply-To: <890818-183407-4872@Xerox>
Message-Id: <19890821183403.7.ALAN@ROCKY.parc.xerox.com>
Line-Fold: no
Date: Fri, 18 Aug 89 18:36:26 PDT
From: Pavel.pa@Xerox.COM
(RECORD-CONSTRUCTOR rtd)
Returns a procedure for constructing new members of the type represented by
rtd. The returned procedure accepts exactly as many arguments as there
were slot-names in the call to MAKE-RECORD-TYPE that created the type
represented by rtd; these are used, in order, as the initial values of
those slots in a new record, which is returned by the constructor
procedure.
I prefer the alternative that someone (RRJ?) made the last time we
discussed this:
(RECORD-CONSTRUCTOR rtd slot-names)
Where slot-names is a subset of the slot-names given to MAKE-RECORD-TYPE.
The returned procedure accepts exactly as many arguments as there are
slot-names. It creates a new record and initializes the specified slots.
Not only is this more flexible, but it is more readable. If you go looking
for the definition of MAKE-SPACESHIP and you find
(DEFINE MAKE-SPACESHIP (RECORD-CONSTRUCTOR SPACESHIP-RTD))
chances are your next move is to go looking for the definition of
SPACESHIP-RTD so you can figure out what the arguments to MAKE-SPACESHIP
are. Ugh. On the other hand, if you find
(DEFINE MAKE-SPACESHIP
(RECORD-CONSTRUCTOR SPACESHIP-RTD '(NAME CAPTAIN)))
chances are good that you won't need to look any further.
=====================
Notes on the proposal
=====================
-- The type-name argument to MAKE-RECORD-TYPE is constrained to be a string
in order to allow experimentation with interesting semantics for other
kinds of values there. One possibility raised in the discussion in 1988
was some kind of a ``handler'' procedure, as in T objects.
Even if someday you can pass a ``handler'' to MAKE-RECORD-TYPE, mightn't
you -also- want to pass a type-name? I don't see how the two are
exclusive.
-- A case can be made that constructor procedures should take no arguments
and leave all slots in new records uninitialized. There appear to be
advantages to both points of view.
I'm not sure I understand why anyone would advocate this. Would such
people be made happy if
(RECORD-CONSTRUCTOR SPACESHIP-RTD '())
returns such a constructor? Or do such people think that the user should
be forced to use side-effects to initialize records?
-- ... The consensus of those I've spoken to concerning EQUAL? is that
it should be equivalent to EQV? on records, instead of treating them as
it treats vectors, pairs, and strings....
My personal preference: I have never wanted to compare records by
comparing their contents slot-by-slot. I -have- wanted to compare two
lists of records to see if they contain the same (EQ) records. The latter
application is at least slow and can also be dangerous if EQUAL? descends
records (the records may be part of a circular structure). That is why I
feel EQUAL? should not descend records.
∂23-Aug-89 2230 @mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@relay.cs.net,@tektronix.tek.com:adams@tekchips.labs.tek.com Programmer-defined data types
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89 22:29:44 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA13061; Thu, 24 Aug 89 01:03:13 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa15594;
21 Aug 89 20:03 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Aug 89 20:03:47 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa15473;
21 Aug 89 19:54 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA06715; Mon, 21 Aug 89 19:54:51 EDT
Received: from life.ai.mit.edu (life.ai.mit.edu) by zurich.ai.mit.edu; Mon, 21 Aug 89 19:51:36 edt
Received: from RELAY.CS.NET by life.ai.mit.edu (4.1/AI-4.10) id AA06690; Mon, 21 Aug 89 19:53:24 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa10653; 21 Aug 89 18:45 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
id AA07835; Mon, 21 Aug 89 15:47:53 PDT
Received: by tekirl.labs.tek.com (5.51/7.1)
id AA12356; Mon, 21 Aug 89 15:45:47 PDT
Received: by tekchips.LABS.TEK.COM (5.51/6.24)
id AA18203; Mon, 21 Aug 89 15:48:14 PDT
Date: Mon, 21 Aug 89 15:48:14 PDT
From: Norman Adams <adams%tekchips.labs.tek.com@relay.cs.net>
Message-Id: <8908212248.AA18203@tekchips.LABS.TEK.COM>
To: RRRS-Authors@zurich.ai.mit.edu
Cc: Pavel.pa@xerox.com
Subject: Programmer-defined data types
I support Pavel's proposal for records.
I would prefer that each abstraction-breaking procedure is identified as
such in its description. I prefer the term "field" to "slot."
-- Should there be a RECORD-COPIER procedure? Some folks would like to
have one for performance and convenience..
I can think of many operations generic to records. I don't think
copying deserves to be a special case.
-Norman
∂24-Aug-89 0210 @mc.lcs.mit.edu:bawden.pa@xerox.com Numbers and Pork Rinds
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 24 Aug 89 02:10:51 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA00766; Thu, 24 Aug 89 05:02:00 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22028;
24 Aug 89 0:31 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 24 Aug 89 00:21:49 EDT
Received: from Xerox.COM by mintaka.lcs.mit.edu id aa19440; 23 Aug 89 21:18 EDT
Received: from Semillon.ms by ArpaGateway.ms ; 23 AUG 89 17:36:27 PDT
Date: Wed, 23 Aug 89 17:33 PDT
From: bawden.pa@xerox.com
Subject: Numbers and Pork Rinds
To: gls@think.com
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: <8908231825.AA13164@verdi.think.com>
Message-Id: <19890824003336.4.ALAN@ROCKY.parc.xerox.com>
Line-Fold: no
Date: Wed, 23 Aug 89 14:25:31 EDT
From: gls@Think.COM (Guy Steele)
Here is where the cart may be before the horse. I'll let you inspect the
*types* of the arguments up front in any case. Are you then deciding a
priori to use floating-point to represent the result only on the basis of
the argument types, without regard to the values involved? Or do you
entertain the possibility that the type (or representation) of the result
may depend on the specific values of the arguments? I am arguing for the
latter.
Of course the type of the answer may depend on more than the datatype of
argument. Consider the case of `*'. In general (* <inexact> <exact>)
yields an inexact number. But in the case of (* <inexact> 0) you may
return an exact 0. If your implementation used interval arithmetic, then
(MAX <inexact> <exact>) may well be able to return an exact number, given
the bounds contained in the inexact argument:
(MAX #<Interval 3 through 5> 10) ==> 10
(MAX #<Interval 9 through 11> 10) ==> #<Interval 10 through 11>
BUT IN THE CASE WHERE FLOATING POINT IS USED I do not believe there is any
case where an exact answer may be returned if one of the arguments is
inexact.
Presumably when you say "perhaps 1000 feet" you mean something different
from "perhaps 4 feet", or otherwise you would not bother; you would have a
single inexact number called "perhaps". There is some level of confidence
that leads you to say "perhaps 100" in preference to any other inexact
result. Am I to regard an inexact number as a probability distribution
(whose shape I may know nothing about)?
No, an inexact number is not necessarily a probability distribution
(although that might be an interesting representation to explore). I can't
tell you what it is in general. Sorry. We aren't specifying the behavior
of inexact numbers here.
All I care about is that MAX not return an exact answer unless the
implementation really -knows- that that exact number is the correct answer.
That's all I care about. Read my lips.
∂24-Aug-89 0323 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #186
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 24 Aug 89 03:23:49 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA00947; Thu, 24 Aug 89 05:43:56 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa24786;
24 Aug 89 3:24 EDT
Date: 24 AUG 89 00:14:20 EDT
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.mc.lcs.edu>
Subject: Scheme Digest #186
To: Scheme%mc.lcs.mit.edu@mintaka.mc.lcs.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.mc.lcs.edu
Message-Id: <8908240324.aa24786@mintaka.lcs.mit.edu>
Scheme Digest #186 24 AUG 89 00:14:20 EDT
Today's Topics:
Problem with XScheme 0.16
----------------------------------------------------------------------
Date: 23 Aug 89 21:12:18 GMT
From: Brian of ASTD-CP <brian@topaz.rutgers.edu>
Subject: Problem with XScheme 0.16
Message-Id: <1639@jato.Jpl.Nasa.Gov>
I have been using XScheme 0.16 for about 6 months, now, and find it
to be quite useful. I have been running it on Silicon Graphics
workstations, specifically, the IRIS 3130 and the Personal Iris.
In all the time I have been using the program, I have found only
one non-trivial bug. The author of XScheme, David Betz, deserves
considerable praise for the robustness and performance of XScheme.
Having been inside the source, I have found it to be some of the
cleanest, easiest-to-understand C code I have ever seen. However,
I have determined that I will be unable to debug the problem
without spending several days instrumenting the code. I have
written to David to ask his help, and I thought I might query the
network, too, in case someone out there has already solved the
problem and can save me those few days' work.
The following operations cause a "segmentation violation" on the
Personal Iris
XScheme version 0.16 (with IRIS graphics primitives)
> (save "foo")
#t
> (restore "foo")
[ returning to the top level ]
> (* 3 4)
Segmentation violation (core dumped)
A traceback shows
putnumber / xsprint / xlprint / xwrite / xlapply / xlexecute / main
with the program dying at line 278 in xsprint.c at the statement
LVAL fmt = getvalue(s_fixfmt) ;
The following sequence may also be instructive.
XScheme version 0.16 (with IRIS graphics primitives)
> (save "foo")
#t
> (restore "foo")
[ returning to top level ]
> (save "bar")
#t
> (exit)
UNIX% cmp foo bar
foo bar differ: char 94, line 1
My intuition tells me that the two files should be identical. To
give some context, the Personal Iris is a MIPS processor, running
Silicon Graphics' own UNIX, part system V, part BSD 4.2. In this
test, I am running XScheme as "clean" as possible, without the file
"xscheme.ini", without syntax extensions, etc. Bringing up XScheme
with my usual environment, which contains hundreds of graphics
definitions, R. K. Dybvig's syntax extender, etc., etc., causes
XScheme to crash deep in the restore statement itself. I have not
modified the XScheme core, that is, David Betz's code. I have only
added graphics routines in new files.
My hunch is that information about the contents of memory is either
not getting saved correctly or not getting restored correctly, and
the next step seems to be to collect information about the save and
restore processes. I spent a couple of hours desk-checking the
code in xsimage.c for "xlsave" and "xlrestore". There is nothing
obviously wrong. I decided that my next step would be to create
versions of save and restore that deal with a printable format, so
I could see what is being saved and restored, and I prepared myself
to build a memory analyzer that would print out the contents of
memory so I could verify that restore is doing the right thing. I'd
like to avoid doing all this if someone out there has already fixed
the problem.
By the way, save and restore are necessary in my graphics work
because I need to be able to load complex graphics models very
quickly, in compiled form, without going through recompilation.
Please e-mail or phone me if you have a solution, and thanks in
advance.
. . . Dr. Brian Beckman . . . . . . . . . . . . 4800 Oak Grove Drive . . . . .
. . . Computer Graphics Laboratory. . . . . . . Pasadena, CA 91109 . . . . . .
. . . MS 510-202, Jet Propulsion Laboratory . . (818) 397-9207 . . . . . . . .
. . . California Institute of Technology. . . . brian@topaz.jpl.nasa.gov . . .
------------------------------
End of Scheme Digest
********************
∂24-Aug-89 0428 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #182
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 24 Aug 89 04:28:03 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA01348; Thu, 24 Aug 89 06:26:03 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa09295;
19 Aug 89 0:42 EDT
Date: 19 AUG 89 00:09:54 EDT
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.mc.lcs.edu>
Subject: Scheme Digest #182
To: Scheme%mc.lcs.mit.edu@mintaka.mc.lcs.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.mc.lcs.edu
Message-Id: <8908190042.aa09295@mintaka.lcs.mit.edu>
Scheme Digest #182 19 AUG 89 00:09:54 EDT
Today's Topics:
Cscheme posting
----------------------------------------------------------------------
Date: 18 Aug 89 17:34:34 GMT
From: Bob Sutterfield <tinman.cis.ohio-state.edu!bob@ohio-state.arpa>
Subject: Re: Cscheme posting
Message-Id: <BOB.89Aug18133434@tinman.cis.ohio-state.edu>
In article <8907241613.AA01903@zurich.ai.mit.edu> cph@ZURICH.AI.MIT.EDU (Chris Hanson) writes:
In article <6592@cognos.UUCP> rossj@cognos.UUCP (Ross Judson) writes:
A month or two ago I read that somebody planned on posting the
most recent version... Unfortunately, I am unable to ftp... So
posting is the only way I'll see it.
There is no chance that anyone will post CScheme -- the current
distribution is 6 megabytes in size, over 2 megabytes when
compressed. You will have to find someone who has a copy and can
get it to you.
I have updated the C Scheme on osu-cis to 7.0, available for anonymous
UUCP. Though it's pretty huge, we now have a TB+ and a V.32 that
should help keep your costs down when you call for it. Write to
osu-cis!uucp (same as uucp@cis.ohio-state.edu) for instructions if you
don't already know how to get the current set.
(BTW, it's not at all safe to say that "there's no chance" of
something stupid happening in the Usenet - someone, somewhere, will
gladly prove you wrong. :-)
------------------------------
End of Scheme Digest
********************
∂24-Aug-89 0504 ramsdell@linus.mitre.org Revised WITH-VALUES and VALUES (I think we are near agreement!)
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 24 Aug 89 05:03:54 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA02200; Thu, 24 Aug 89 07:44:51 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA04381; Thu, 24 Aug 89 07:39:23 EDT
Posted-Date: Thu, 24 Aug 89 07:39:19 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA10826; Thu, 24 Aug 89 07:39:21 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8908241139.AA10826@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Cc: ramsdell@linus.mitre.org
Subject: Revised WITH-VALUES and VALUES (I think we are near agreement!)
Date: Thu, 24 Aug 89 07:39:19 EDT
>> From: Guillermo J. Rozas <jinx@hpesogg.hp.com>
>>...
>> I will accept the proposal if it leaves the arity of implicit
>> continuations unspecified, and it is explicitely stated.
Here is my rewrite. I interpret your request as follows. If the
arity of implicit continuations is unspecified we plan to allow both
implementations using implicit continuations which require exactly one
value and those using continuations which accept one or more values.
In particular, if the arity of implicit continuations are unspecified,
some implementations may signal an error when given more than one
value. As I understand R4RS lingo, I must use the phrase "an error"
to describe situations in which some implementations can signal an
error, and others do not have to. The phrase "unspecified" means that
no error can be reported which would imply that the arity of implicit
continuations are specified. Please bless this or suggest an
alternate wording.
John
---------------
(values obj ...) essential procedure
Returns 0 or more values to a receiving procedure (See with-values).
(values) => returns zero (no) values
(values 1) => returns a single value, 1
(values 1 'a) => returns two values, 1 and the symbol a
Values applied to one argument simply returns its argument. Returning
more than one value or zero values to something other than a receiving
procedure is an error.
(with-values generator receiver) essential procedure
Returns the result of applying the procedure 'receiver' to the values
produced by calling procedure 'generator' with no arguments. It is an
error if 'receiver' cannot be applied to the number of values returned
by 'generator' or if 'generator' cannot be called with zero arguments.
(with-values
(lambda ()
(values 1 2))
cons) => (1 . 2)
--------------------------------
∂24-Aug-89 0600 @mc.lcs.mit.edu:bawden.pa@xerox.com Numbers
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 24 Aug 89 06:00:02 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA02707; Thu, 24 Aug 89 08:49:05 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa16115;
21 Aug 89 20:38 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Aug 89 20:38:08 EDT
Received: from Xerox.COM by mintaka.lcs.mit.edu id aa16079; 21 Aug 89 20:35 EDT
Received: from Semillon.ms by ArpaGateway.ms ; 21 AUG 89 17:34:35 PDT
Date: Mon, 21 Aug 89 17:24 PDT
From: bawden.pa@xerox.com
Subject: Numbers
To: gls@think.com
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: <8908211534.AA29201@verdi.think.com>
Message-Id: <19890822002405.2.ALAN@ROCKY.parc.xerox.com>
Line-Fold: no
Date: Mon, 21 Aug 89 11:34:37 EDT
From: Guy Steele <gls@think.com>
I'm back from an exhausting, and therefore very restful, vacation.
Back into the fray!
I was wondering why I hadn't heard from you. I couldn't imagine that you
had given up the argument!
Here is a new proposal. Given a set of points within a partial order,
there are two interesting kinds of "max"-like operation. One is to find
some point (not necessarily within the set) that is >= all points in the
given set; this is SUP....
Another is to find some point in the set such that no point in the set is >
that point....
But the version of MAX I am advocating isn't either of these! I would
allow:
(max 1.0 549755813889) ==> 549755813888.0
Where presumably (< 549755813888.0 549755813889) is true. Thus MAX can
return an object that, according to `<', is smaller than one of the
arguments.
Now I'm sure that about half of you are shouting at your terminal about how
I couldn't -possibly- mean that, but I do. Understand me once and for all:
INEXACT NUMBERS ARE NOT NUMBERS
INEXACT NUMBERS ARE NOT NUMBERS
INEXACT NUMBERS ARE NOT NUMBERS
They do not obey the rules followed by numbers, because they cannot.
Inexact numbers only represent our -approximate- -knowledge- about numbers.
In
(max 1.0 549755813889) ==> 549755813888.0
we strongly suspect that the first number is 1, but we don't know for sure.
Thus we strongly suspect that the answer is 549755813889, but again we
don't know for sure (the first number could have actually been
549755813890). Since we don't know the answer for sure, we must return an
inexact representation of our best guess. 549755813888.0 is the closest we
can come. (The next larger might be 549755879424.0, assuming 23 bits of
floating point precision, which is not very close at all.)
Indeed, we could -specify- that MAX always ``round up'' in the inexact case
so that the result always appears greater (accroding to `<') than any of
the arguments. This would be similar to specifying that `<' must always
behave transitively. It would be a feeble attempt on our part to paper
over the ugly fact that -in- -general-, inexact numbers do not obey the
axioms of arithmetic.
∂24-Aug-89 0629 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #183
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 24 Aug 89 06:29:15 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA02557; Thu, 24 Aug 89 08:42:13 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22139;
20 Aug 89 0:04 EDT
Date: 20 AUG 89 00:02:31 EDT
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.mc.lcs.edu>
Subject: Scheme Digest #183
To: Scheme%mc.lcs.mit.edu@mintaka.mc.lcs.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.mc.lcs.edu
Message-Id: <8908200004.aa22139@mintaka.lcs.mit.edu>
Scheme Digest #183 20 AUG 89 00:02:31 EDT
Today's Topics:
Don't Read This If You Get Tired Easily At Whiney Requests
----------------------------------------------------------------------
Date: 19 Aug 89 02:58:33 GMT
From: "Jack J. Woehr" <cs.utexas.edu!sun-barr!apple!well!jax@ohio-state.arpa>
Subject: Don't Read This If You Get Tired Easily At Whiney Requests
Message-Id: <13213@well.UUCP>
blah, blah, blah, latest version on Amiga? blah blah blah ...
------------------------------
End of Scheme Digest
********************
∂24-Aug-89 1002 cph@zurich.ai.mit.edu Revised WITH-VALUES and VALUES (I think we are near agreement!)
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 24 Aug 89 10:02:47 PDT
Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA04241; Thu, 24 Aug 89 12:13:02 EDT
Received: from localhost by zurich.ai.mit.edu; Thu, 24 Aug 89 12:09:48 edt
Date: Thu, 24 Aug 89 12:09:48 edt
From: cph@zurich.ai.mit.edu (Chris Hanson)
Message-Id: <8908241609.AA12852@zurich.ai.mit.edu>
To: ramsdell@linus.mitre.org
Cc: rrrs-authors@life.ai.mit.edu
In-Reply-To: ramsdell@linus.mitre.org's message of Thu, 24 Aug 89 07:39:19 EDT <8908241139.AA10826@huxley.mitre.org>
Subject: Revised WITH-VALUES and VALUES (I think we are near agreement!)
From: ramsdell@linus.mitre.org
Date: Thu, 24 Aug 89 07:39:19 EDT
(values obj ...) essential procedure
Returns 0 or more values to a receiving procedure (See with-values).
(values) => returns zero (no) values
(values 1) => returns a single value, 1
(values 1 'a) => returns two values, 1 and the symbol a
Values applied to one argument simply returns its argument. Returning
more than one value or zero values to something other than a receiving
procedure is an error.
May I suggest rewording the last sentence as follows? This eliminates
a small ambiguity.
"Returning zero values or more than one value to something other than
a receiving procedure is an error."
∂24-Aug-89 1009 gls@think.com Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 24 Aug 89 10:09:43 PDT
Received: from Think.COM (Gateway.Think.COM) by life.ai.mit.edu (4.1/AI-4.10) id AA03436; Thu, 24 Aug 89 10:26:25 EDT
Received: from fafnir.think.com by Think.COM; Thu, 24 Aug 89 10:26:06 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Thu, 24 Aug 89 10:23:28 EDT
Received: by verdi.think.com; Thu, 24 Aug 89 10:23:14 EDT
Date: Thu, 24 Aug 89 10:23:14 EDT
From: gls@think.com (Guy Steele)
Message-Id: <8908241423.AA28886@verdi.think.com>
To: dyb@iuvax.cs.indiana.edu
Cc: gls@think.com, rrrs-authors@life.ai.mit.edu
In-Reply-To: R. Kent Dybvig's message of Wed, 23 Aug 89 16:33:43 -0500 <8908232205.AA29152@Think.COM>
Subject: Multiple values for R4RS.
Date: Wed, 23 Aug 89 16:33:43 -0500
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
> You could always walk down the machine language code, trying to figure
> out which registers or stack slots it is touching in order to fetch arguments.
> (This is not a claim of good engineering, just an existence proof.)
> --Guy
Are you assuming that there are explicit references to the registers or
stack slots holding the values? There may in fact be no such
references. Perhaps the code performs some sort of computation to
derive an index into the stack holding the argument and the value of
that computation cannot be determined. Or perhaps the code does not
touch one or more of its arguments explicitly, but leaves them in place
as arguments to another procedure that it calls.
Kent
Each implementor presumably will know whether his/her compiler generates
code obeying sufficient constraints that this technique will work.
Don't overlook the possibility of limited abstract simulation of the machine
code. My point is that under *some* circumstances it is not necessary
to encode the arity separately.
--Guy
∂24-Aug-89 1202 ramsdell@linus.mitre.org Re: Revised WITH-VALUES and VALUES (I think we are near agreement!)
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 24 Aug 89 12:02:35 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA05575; Thu, 24 Aug 89 14:28:08 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA09690; Thu, 24 Aug 89 14:28:49 EDT
Posted-Date: Thu, 24 Aug 89 14:22:31 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA11476; Thu, 24 Aug 89 14:22:32 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8908241822.AA11476@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Subject: Re: Revised WITH-VALUES and VALUES (I think we are near agreement!)
In-Reply-To: Your message of Thu, 24 Aug 89 12:09:48 -0400.
<8908241609.AA12852@zurich.ai.mit.edu>
Date: Thu, 24 Aug 89 14:22:31 EDT
I take Chris's suggestion as a friendly amendment and accept it unless
some one objects.
John
>> From: cph@zurich.ai.mit.edu (Chris Hanson)
...
>> May I suggest rewording the last sentence as follows? This eliminates
>> a small ambiguity.
>>
>> "Returning zero values or more than one value to something other than
>> a receiving procedure is an error."
∂25-Aug-89 0414 @mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu Programmer-defined data types
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 25 Aug 89 04:14:19 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA00985; Fri, 25 Aug 89 05:42:02 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa01808;
24 Aug 89 13:46 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 24 Aug 89 13:46:19 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa00637;
24 Aug 89 12:01 EDT
Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA04169; Thu, 24 Aug 89 11:58:34 EDT
Received: from localhost by zurich.ai.mit.edu; Thu, 24 Aug 89 11:55:21 edt
Date: Thu, 24 Aug 89 11:55:21 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
Message-Id: <8908241555.AA11386@zurich.ai.mit.edu>
To: bawden.pa@xerox.com
Cc: Pavel.pa@xerox.com, RRRS-Authors@zurich.ai.mit.edu
In-Reply-To: bawden.pa@xerox.com's message of Mon, 21 Aug 89 11:34 PDT <19890821183403.7.ALAN@ROCKY.parc.xerox.com>
Subject: Programmer-defined data types
Date: Mon, 21 Aug 89 11:34 PDT
From: bawden.pa@xerox.com
Line-Fold: no
Date: Fri, 18 Aug 89 18:36:26 PDT
From: Pavel.pa@Xerox.COM
(RECORD-CONSTRUCTOR rtd)
Returns a procedure for constructing new members of the type represented by
rtd. The returned procedure accepts exactly as many arguments as there
were slot-names in the call to MAKE-RECORD-TYPE that created the type
represented by rtd; these are used, in order, as the initial values of
those slots in a new record, which is returned by the constructor
procedure.
I prefer the alternative that someone (RRJ?) made the last time we
discussed this:
(RECORD-CONSTRUCTOR rtd slot-names)
Where slot-names is a subset of the slot-names given to MAKE-RECORD-TYPE.
The returned procedure accepts exactly as many arguments as there are
slot-names. It creates a new record and initializes the specified slots.
I agree with this wholeheartedly. I think this form of the
constructor-constructor is significantly more useful.
-- A case can be made that constructor procedures should take no arguments
and leave all slots in new records uninitialized. There appear to be
advantages to both points of view.
I'm not sure I understand why anyone would advocate this. Would such
people be made happy if
(RECORD-CONSTRUCTOR SPACESHIP-RTD '())
returns such a constructor? Or do such people think that the user should
be forced to use side-effects to initialize records?
If it is the case that there are advantages to both points of view,
then whatever is provided should support both. I think Alan's
suggestion does this.
∂25-Aug-89 1016 @mc.lcs.mit.edu,@gateway.think.com:gls@think.com Numbers and Pork Rinds
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 25 Aug 89 10:16:19 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA04768; Fri, 25 Aug 89 12:57:30 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa02281;
24 Aug 89 14:14 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 24 Aug 89 13:49:58 EDT
Received: from Gateway.Think.COM by mintaka.lcs.mit.edu id aa01560;
24 Aug 89 13:30 EDT
Received: from fafnir.think.com by Think.COM; Thu, 24 Aug 89 12:31:35 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Thu, 24 Aug 89 12:28:57 EDT
Received: by verdi.think.com; Thu, 24 Aug 89 12:28:42 EDT
Date: Thu, 24 Aug 89 12:28:42 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8908241628.AA00798@verdi.think.com>
To: bawden.pa@xerox.com
Cc: gls@think.com, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: bawden.pa@xerox.com's message of Wed, 23 Aug 89 17:33 PDT <19890824003336.4.ALAN@ROCKY.parc.xerox.com>
Subject: Numbers and Pork Rinds
Date: Wed, 23 Aug 89 17:33 PDT
From: bawden.pa@xerox.com
Date: Wed, 23 Aug 89 14:25:31 EDT
From: gls@Think.COM (Guy Steele)
Here is where the cart may be before the horse. I'll let you inspect the
*types* of the arguments up front in any case. Are you then deciding a
priori to use floating-point to represent the result only on the basis of
the argument types, without regard to the values involved? Or do you
entertain the possibility that the type (or representation) of the result
may depend on the specific values of the arguments? I am arguing for the
latter.
Of course the type of the answer may depend on more than the datatype of
argument. Consider the case of `*'. In general (* <inexact> <exact>)
yields an inexact number. But in the case of (* <inexact> 0) you may
return an exact 0. If your implementation used interval arithmetic, then
(MAX <inexact> <exact>) may well be able to return an exact number, given
the bounds contained in the inexact argument:
(MAX #<Interval 3 through 5> 10) ==> 10
(MAX #<Interval 9 through 11> 10) ==> #<Interval 10 through 11>
BUT IN THE CASE WHERE FLOATING POINT IS USED I do not believe there is any
case where an exact answer may be returned if one of the arguments is
inexact.
Very well; we are making progress. You do admit that in some circumstances,
in some implementations, it may make sense for (max 4.0 1000) to return an
exact 1000, say in the case where "4.0" is interpreted by the reader to
mean "the interval from 3.95 to 4.05".
My argument, then, is as follows. Floating-point is indeed so screwed up
that the implementor cannot a priori regard them as intervals or as
anything else interesting, and therefore cannot return an exact result for
the supremum operation. HOWEVER, in some cases the user, knowing the
properties of the floating-point arithmetic, can with his additional
understanding determine that they may be regarded as intervals (or
something close to that) for his purposes. Therefore the user should be
given a choice. LARGEST and SMALLEST may be useful alternatives; *but* I
have also managed to argue that their use is not portable. (On the other
hand, many uses of inexact arithmetic will be nonportable in precisely the
same manner, so to this we should not attach too great a stigma.)
Presumably when you say "perhaps 1000 feet" you mean something different
from "perhaps 4 feet", or otherwise you would not bother; you would have a
single inexact number called "perhaps". There is some level of confidence
that leads you to say "perhaps 100" in preference to any other inexact
result. Am I to regard an inexact number as a probability distribution
(whose shape I may know nothing about)?
No, an inexact number is not necessarily a probability distribution
(although that might be an interesting representation to explore). I can't
tell you what it is in general. Sorry. We aren't specifying the behavior
of inexact numbers here.
I meant "probability distribution" to be not an implementation
representation, but a conceptual model that might cover all representations
in one way or another. But that's a side point; you didn't address my main
question. If inexactness is considered by the Scheme standard merely to be
a scarlet letter indicating that a value is in a state of sin and is
therefore not to be trusted (for inexact arithmetic, while required to
strive for "high quality", has no particular portable requirements), then I
want to know how it is that you can ever think that "perhaps 1000" can ever
be said rather than merely "perhaps"; in other words, without some further
requirements on, or knowledge of, the quality of a particular
implementation, why is it not my duty to regard *every* inexact number as
representing merely "perhaps"?
All I care about is that MAX not return an exact answer unless the
implementation really -knows- that that exact number is the correct answer.
That's all I care about. Read my lips.
Okay. Up to now I had understood you additionally to argue that
the implementation can't ever know that for LARGEST, and therefore
LARGEST is a bogus concept. Now that we have found a circumstance
when the implementation *can* know, we have proved that LARGEST is
not bogus. A separate argument now concerns whether it is useless.
But I think I am about to run out of steam. Alan and I have aired
our views pretty thoroughly, tying up a lot of mailboxes in the process.
Hey, all you out there: does anyone else care? Has anyone's mind been
changed as a result of our discussion?
--Guy
∂25-Aug-89 1054 jinx@hpesogg.hp.com Revised WITH-VALUES and VALUES (I think we are near agreement!)
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 25 Aug 89 10:53:53 PDT
Received: from sde.hp.com (hp-sde.sde.hp.com) by life.ai.mit.edu (4.1/AI-4.10) id AA05104; Fri, 25 Aug 89 13:35:25 EDT
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA06076; Thu, 24 Aug 89 16:23:31 pdt
Message-Id: <8908242323.AA06076@sde.hp.com>
Received: by hpesogg; Thu, 24 Aug 89 16:22:48 pdt
Date: Thu, 24 Aug 89 16:22:48 pdt
From: Guillermo J. Rozas <jinx@hpesogg.hp.com>
To: ramsdell@linus.mitre.org
Cc: rrrs-authors@life.ai.mit.edu, ramsdell@linus.mitre.org
In-Reply-To: ramsdell@linus.mitre.org's message of Thu, 24 Aug 89 07:39:19 EDT <8908241139.AA10826@huxley.mitre.org>
Subject: Revised WITH-VALUES and VALUES (I think we are near agreement!)
Reply-To: jinx%hpesogg@sde.hp.com
I must use the phrase "an error"
to describe situations in which some implementations can signal an
error, and others do not have to.
The meaning of "is an error" is that the program is incorrect, but the
implementation may not signal the violation. This goes very much
against the grain of what I want, since it says that the program was
illegal in the first place.
I would rather say that the implementation may report the violation of
an implementation restriction (just like in the numeric section). The
program is not in error, neither is the implementation, there is
purely a mismatch.
∂25-Aug-89 1151 ramsdell@linus.mitre.org Re: Revised WITH-VALUES and VALUES (I think we are near agreement!)
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 25 Aug 89 11:51:07 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA05921; Fri, 25 Aug 89 14:32:17 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA28340; Fri, 25 Aug 89 14:32:52 EDT
Posted-Date: Fri, 25 Aug 89 14:26:35 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA14483; Fri, 25 Aug 89 14:26:36 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8908251826.AA14483@huxley.mitre.org>
To: jinx%hpesogg@sde.hp.com
Cc: rrrs-authors@life.ai.mit.edu
Subject: Re: Revised WITH-VALUES and VALUES (I think we are near agreement!)
In-Reply-To: Your message of Thu, 24 Aug 89 16:22:48 -0700.
<8908242323.AA06076@sde.hp.com>
Date: Fri, 25 Aug 89 14:26:35 EDT
>> From: Guillermo J. Rozas <jinx@hpesogg.hp.com>
>>
>> The meaning of "is an error" is that the program is incorrect, but the
>> implementation may not signal the violation. This goes very much
>> against the grain of what I want, since it says that the program was
>> illegal in the first place.
>>
I didn't think you would like the "is an error" part. Maybe now you
will appreciate the fact that in a previous proposal, nothing was said
about what happens in the case in which zero values or more than one
value are returned to something other than a receiving procedure. By
saying nothing about that case, programs which rely on the truncation
of multiple values are not labeled as being illegal, but not all
implementations are required to run those programs. In a nut shell, I
think that is the essence of the compromise. Given that
clarification, please reconsider the proposal in which the following
sentence:
Values applied to one argument simply returns its argument.
replaces the paragraph:
Values applied to one argument simply returns its argument.
Returning zero values or more than one value to something other
than a receiving procedure is an error.
If this proposal is not to your liking, please submit a replacement
paragraph which is consistant with the notation and terminology of
R3.95RS.
John
∂25-Aug-89 1221 jinx@hpesogg.hp.com Revised WITH-VALUES and VALUES (I think we are near agreement!)
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 25 Aug 89 12:20:55 PDT
Received: from sde.hp.com (hp-sde.sde.hp.com) by life.ai.mit.edu (4.1/AI-4.10) id AA06214; Fri, 25 Aug 89 14:57:14 EDT
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA05933; Thu, 24 Aug 89 16:18:53 pdt
Message-Id: <8908242318.AA05933@sde.hp.com>
Received: by hpesogg; Thu, 24 Aug 89 16:18:12 pdt
Date: Thu, 24 Aug 89 16:18:12 pdt
From: Guillermo J. Rozas <jinx@hpesogg.hp.com>
To: ramsdell@linus.mitre.org
Cc: rrrs-authors@life.ai.mit.edu, ramsdell@linus.mitre.org
In-Reply-To: ramsdell@linus.mitre.org's message of Thu, 24 Aug 89 07:39:19 EDT <8908241139.AA10826@huxley.mitre.org>
Subject: Revised WITH-VALUES and VALUES (I think we are near agreement!)
Reply-To: jinx%hpesogg@sde.hp.com
Values applied to one argument simply returns its argument. Returning
more than one value or zero values to something other than a receiving
procedure is an error.
Isn't this saying that it is an error to return 2 values to an
implicit continuation? If so, I don't like it.
∂25-Aug-89 1234 ramsdell@linus.mitre.org "is an error" -> "is undefined"
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 25 Aug 89 12:34:20 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA06306; Fri, 25 Aug 89 15:07:06 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA28665; Fri, 25 Aug 89 15:08:12 EDT
Posted-Date: Fri, 25 Aug 89 15:01:55 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA14518; Fri, 25 Aug 89 15:01:56 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8908251901.AA14518@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Subject: "is an error" -> "is undefined"
In-Reply-To: Your message of Fri, 25 Aug 89 14:51:00 -0400.
<19890825185146.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Fri, 25 Aug 89 15:01:55 EDT
>> From: ramsdell@linus.MITRE.ORG
...
>> If this proposal is not to your liking, please submit a replacement
>> paragraph which is consistant with the notation and terminology of
>> R3.95RS.
>>
>> John
I was wrong to be so restrictive. Kent M Pitman is right about the
alternative possibility of you proposing new notation and terminology
to cover this case. That is, maybe by replacing the phrase "is an
error" with "is undefined", and adding the appropriate definition of
"is undefined", we will have a proposal acceptable to all.
John
∂25-Aug-89 1237 KMP@stony-brook.scrc.symbolics.com Revised WITH-VALUES and VALUES (I think we are near agreement!)
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 25 Aug 89 12:36:37 PDT
Received: from STONY-BROOK.SCRC.Symbolics.COM by life.ai.mit.edu (4.1/AI-4.10) id AA06151; Fri, 25 Aug 89 14:51:25 EDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 647500; 25 Aug 89 14:51:59 EDT
Date: Fri, 25 Aug 89 14:51 EDT
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Subject: Revised WITH-VALUES and VALUES (I think we are near agreement!)
To: jinx%hpesogg@sde.hp.com
Cc: ramsdell@linus.mitre.org, rrrs-authors@life.ai.mit.edu
In-Reply-To: <8908242323.AA06076@sde.hp.com>
Message-Id: <19890825185146.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Thu, 24 Aug 89 16:22:48 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: ramsdell@linus.mitre.org
I must use the phrase "an error"
to describe situations in which some implementations can signal an
error, and others do not have to.
The meaning of "is an error" is that the program is incorrect, but the
implementation may not signal the violation. This goes very much
against the grain of what I want, since it says that the program was
illegal in the first place.
I would rather say that the implementation may report the violation of
an implementation restriction (just like in the numeric section). The
program is not in error, neither is the implementation, there is
purely a mismatch.
Any encoding of information (such as an English sentence or a computer
program) must have -implicit- in it an encoding strategy. You cannot
say "oh, and by the way, this sentence is in English" at the end of a
sentence because that phrase may be interpreted differently in another
language. In the end, it's a grand leap of faith that anyone ever
understands anything anyone else says.
By my terminology, a mismatch can occur only when someone tries to run
an interpreter on a piece of code that it was not intended to be run on.
e.g.,
(PRINT (+ (VALUES 1 2) 3))
If you try to evaluate it in Scheme and it gives you an error, someone
in the office nearby might be right for saying "You dummy. That file was
named foo.lisp, not foo.scheme. It was never intended to work there.
You have a program/language mismatch."
By my terminology, once you've established the dialect which you believe
should be used to interpret the sentences in your language, it is
appropriate to call those things which are not well-defined `errors.'
Calling them errors does not entail signalling an error because the
behavior in an error situation need not be well-defined. It is this
property which allows you to establish a conforming processor of Scheme
which also supports an interesting superset.
My assumption is that you are really just fearing that saying that such
an expression "is an error" means that you are precluded from defining
it in a superset, which I don't think is Ramsdell's intent.
Btw, in our work on ANSI CL, we found the phrase "is an error" to be too
broad for practical purposes. It is well-defined, but it spans a number
of cases which people would like to be distinct. Mostly it does not
distinguish between cases where you left something undefined for
efficiency reasons (e.g., it might be too hard to check type information
on + in code compiled for speed) vs something you left undefined because
two stubborn factions couldn't agree (e.g., this issue of truncating
VALUES).
The net result for Common Lisp was that the old CLtL "is an error"
terminology will be replaced in ANSI CL by a whole bunch of new terms,
which cover the same turf in more refined fashion. The phrase "is an
error" will still have meaning in ANSI CL, but it will be a synonym for
the new and more preferred phrase "is undefined"--and it still fails to
distinguish the intent of leaving something undefined. To fix that, we
added more specific terms which we try to use where appropriate. e.g.,
"should signal an error" was introduced as a refinement of "is an error"
for cases where implementations are not free to extend the functionality
and where they must detect and signal the error when code is processed
in the highest safety setting. There are several other such refined
phrases which attempt to offer more intent about why something is
undefined. I could pass along the current draft meanings of those terms
if anyone on Scheme was serious about establishing some more refined
error terminology.
[Also, my AI Lab working paper ``Exceptional Situations In Lisp'' deals
at more length and with much greater clarity on some of these issues
than I have done here. Anyone interested in a copy can send me mail
privately with their address and I'll try to mail them a copy--I don't
think MIT still stocks it since it was only a working paper and never
promoted to memo status.]
∂25-Aug-89 1726 jinx@hpesogg.hp.com "is an error" -> "is undefined"
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 25 Aug 89 17:25:58 PDT
Received: from sde.hp.com (hp-sde.sde.hp.com) by life.ai.mit.edu (4.1/AI-4.10) id AA09646; Fri, 25 Aug 89 19:51:06 EDT
Received: from hpesogr.cup.hp.com by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA09599; Fri, 25 Aug 89 16:49:55 pdt
Message-Id: <8908252349.AA09599@sde.hp.com>
Received: by hpesogg; Fri, 25 Aug 89 16:49:11 pdt
Date: Fri, 25 Aug 89 16:49:11 pdt
From: Guillermo J. Rozas <jinx@hpesogg.hp.com>
To: ramsdell@linus.mitre.org
Cc: rrrs-authors@life.ai.mit.edu
In-Reply-To: ramsdell@linus.mitre.org's message of Fri, 25 Aug 89 15:01:55 EDT <8908251901.AA14518@huxley.mitre.org>
Subject: "is an error" -> "is undefined"
Reply-To: jinx%hpesogg@sde.hp.com
I was wrong to be so restrictive. Kent M Pitman is right about the
alternative possibility of you proposing new notation and terminology
to cover this case. That is, maybe by replacing the phrase "is an
error" with "is undefined", and adding the appropriate definition of
"is undefined", we will have a proposal acceptable to all.
Undefined is fine with me. I previously suggested the possibility of
phrasing it as an implementation restriction. That would also be
fine.
I definitely do not want anything about an error said.
∂25-Aug-89 1749 jinx@hpesogg.hp.com Revised WITH-VALUES and VALUES (I think we are near agreement!)
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 25 Aug 89 17:48:18 PDT
Received: from sde.hp.com (hp-sde.sde.hp.com) by life.ai.mit.edu (4.1/AI-4.10) id AA09774; Fri, 25 Aug 89 20:13:38 EDT
Received: from hpesogr.cup.hp.com by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA10613; Fri, 25 Aug 89 17:12:58 pdt
Message-Id: <8908260012.AA10613@sde.hp.com>
Received: by hpesogg; Fri, 25 Aug 89 17:12:16 pdt
Date: Fri, 25 Aug 89 17:12:16 pdt
From: Guillermo J. Rozas <jinx@hpesogg.hp.com>
To: KMP@stony-brook.scrc.symbolics.com
Cc: ramsdell@linus.mitre.org, rrrs-authors@life.ai.mit.edu
In-Reply-To: Kent M Pitman's message of Fri, 25 Aug 89 14:51 EDT <19890825185146.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: Revised WITH-VALUES and VALUES (I think we are near agreement!)
Reply-To: jinx%hpesogg@sde.hp.com
I would rather say that the implementation may report the violation of
an implementation restriction (just like in the numeric section). The
program is not in error, neither is the implementation, there is
purely a mismatch.
Any encoding of information (such as an English sentence or a computer
program) must have -implicit- in it an encoding strategy. You cannot
say "oh, and by the way, this sentence is in English" at the end of a
sentence because that phrase may be interpreted differently in another
language. In the end, it's a grand leap of faith that anyone ever
understands anything anyone else says.
By my terminology, a mismatch can occur only when someone tries to run
an interpreter on a piece of code that it was not intended to be run on.
e.g.,
(PRINT (+ (VALUES 1 2) 3))
If you try to evaluate it in Scheme and it gives you an error, someone
in the office nearby might be right for saying "You dummy. That file was
named foo.lisp, not foo.scheme. It was never intended to work there.
You have a program/language mismatch."
Hah? I did not suggest a particular wording. I suggested something
like what I would like to see. I would have written it in a different
paragraph or in double quotes if I intended those exact words to be
used. I know that I'm not good at choosing words.
My assumption is that you are really just fearing that saying that such
an expression "is an error" means that you are precluded from defining
it in a superset, which I don't think is Ramsdell's intent.
R3RS (and I think R3.95RS, but I don't have a copy with me) defines "is
an error" as
When speaking of an error situation, this report uses the phrase "an
error is signalled" to indicate that implementations must detect and
report the error. If such wording does not appear in the discussion
of an error, then implementations are not required to detect or report
the error, though they are encouraged to do so. An error situation
that implementations are not required to detect is usually referred to
simply as "an error".
Thus if the reports defines something to be an error, a user has a
right to claim that I am sloppy or lax if I don't detect it, although
it may be my right.
I want no such connotation associated with returning one more than one
value to an implicit continuation.
That is why I raised the possibility of phrasing it as the violation
of an implementation restriction, which R3.95RS already defines for
numeric "mismatches".
Defining further terminology, or using unspecified or undefined is
fine by me.
∂25-Aug-89 2303 @mc.lcs.mit.edu:bawden.pa@xerox.com Numbers and Pork Rinds
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 25 Aug 89 23:03:38 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA13142; Sat, 26 Aug 89 01:48:15 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa11321;
25 Aug 89 2:21 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 25 Aug 89 02:21:50 EDT
Received: from Xerox.COM by mintaka.lcs.mit.edu id aa11315; 25 Aug 89 2:20 EDT
Received: from Semillon.ms by ArpaGateway.ms ; 24 AUG 89 23:13:15 PDT
Date: Thu, 24 Aug 89 17:37 PDT
From: bawden.pa@xerox.com
Subject: Numbers and Pork Rinds
To: gls@think.com
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: <8908241628.AA00798@verdi.think.com>
Message-Id: <19890825003740.7.ALAN@ROCKY.parc.xerox.com>
Line-Fold: no
Date: Thu, 24 Aug 89 12:28:42 EDT
From: gls@Think.COM (Guy Steele)
Date: Wed, 23 Aug 89 17:33 PDT
From: bawden.pa@xerox.com
(MAX #<Interval 3 through 5> 10) ==> 10
(MAX #<Interval 9 through 11> 10) ==> #<Interval 10 through 11>
BUT IN THE CASE WHERE FLOATING POINT IS USED I do not believe there is any
case where an exact answer may be returned if one of the arguments is
inexact.
Very well; we are making progress. You do admit that in some circumstances,
in some implementations, it may make sense for (max 4.0 1000) to return an
exact 1000, say in the case where "4.0" is interpreted by the reader to
mean "the interval from 3.95 to 4.05".
This is not a new admission on my part. I'm pretty sure I've be saying
parenthetically all along that if you use interval arithmetic you might be
able to return an exact answer. I may have slacked off on beating that
particular point recently because it gets rather tiresome to be constantly
decorating my arguments with little qualifications of the form: "(assuming
we are using floating point)" and "(unless you are using interval
arithmetic or continued fractions)".
My argument, then, is as follows. Floating-point is indeed so screwed up
that the implementor cannot a priori regard them as intervals or as
anything else interesting, and therefore cannot return an exact result for
the supremum operation. HOWEVER, in some cases the user, knowing the
properties of the floating-point arithmetic, can with his additional
understanding determine that they may be regarded as intervals (or
something close to that) for his purposes. Therefore the user should be
given a choice. LARGEST and SMALLEST may be useful alternatives; *but* I
have also managed to argue that their use is not portable. (On the other
hand, many uses of inexact arithmetic will be nonportable in precisely the
same manner, so to this we should not attach too great a stigma.)
No only are uses of LARGEST and SMALLEST non-portable, but LARGEST and
SMALLEST are also very easy for the user to write himself. In fact, a user
with a sufficient understanding of the properties of the inexact arithmetic
in a given implementation may be able to write all kinds of non-portable
things that work correctly to solve his problem -- but that doesn't mean
that we should be putting such things in the language.
... We aren't specifying the behavior of inexact numbers here.
If inexactness is considered by the Scheme standard merely to be a
scarlet letter indicating that a value is in a state of sin and is
therefore not to be trusted (for inexact arithmetic, while required to
strive for "high quality", has no particular portable requirements),
then I want to know how it is that you can ever think that "perhaps
1000" can ever be said rather than merely "perhaps"; in other words,
without some further requirements on, or knowledge of, the quality of a
particular implementation, why is it not my duty to regard *every*
inexact number as representing merely "perhaps"?
In the absence of any other constraints on the behavior of inexact numbers,
an implementation in which there is just -one- inexact number would be
legal. We could even call it "perhaps". I'm not sure this would be any
more useful than an implementation that didn't have any inexacts at all and
signalled an error when it couldn't produce an exact answer. Now I don't
recall what set of constraints are currently in the draft report, but there
was a time when some language ruled out having just #<Perhaps>. But none
of this has anything to do with the issue of MAX/MIN, which is purely a
consequence of the desired properties of -exact- numbers.
All I care about is that MAX not return an exact answer unless the
implementation really -knows- that that exact number is the correct answer.
That's all I care about. Read my lips.
Okay. Up to now I had understood you additionally to argue that
the implementation can't ever know that for LARGEST, and therefore
LARGEST is a bogus concept.
See above. I have tried very hard to -never- say that the implementation
"can't ever know" anything without qualifying it by saying: "assuming
floating point". I don't know what it means for LARGEST to be a "bogus
concept". All I know is that it isn't the right procedure to give to the
users as MAX.
Now that we have found a circumstance
when the implementation *can* know, we have proved that LARGEST is
not bogus.
Huh? The circumstances when the -implementation- can know the exact result
from a call to MAX with an inexact argument are when something other than
floating point is being used. But what does this have to do with LARGEST?
I don't follow this.
A separate argument now concerns whether it is useless.
Since the user can write it himself so easily it better be pretty damn
usefull before we should put it in the language.
But I think I am about to run out of steam. Alan and I have aired
our views pretty thoroughly, tying up a lot of mailboxes in the process.
Hey, all you out there: does anyone else care? Has anyone's mind been
changed as a result of our discussion?
I'll bet most people haven't been paying attention. I fully expect to have
to repeat this entire argument every six months for the rest of my life.
∂26-Aug-89 0100 @mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@relay.cs.net,@tektronix.tek.com:adams@tekchips.labs.tek.com Programmer-defined data types
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 26 Aug 89 01:00:52 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA00440; Sat, 26 Aug 89 03:53:25 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa16162;
25 Aug 89 11:46 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 25 Aug 89 11:46:50 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa16101;
25 Aug 89 11:41 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA04102; Fri, 25 Aug 89 11:41:08 EDT
Received: from RELAY.CS.NET (relay.cs.net) by zurich.ai.mit.edu; Fri, 25 Aug 89 11:37:55 edt
Received: from tektronix.tek.com by RELAY.CS.NET id aa07728; 25 Aug 89 11:40 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
id AA11688; Fri, 25 Aug 89 08:42:51 PDT
Received: by tekirl.labs.tek.com (5.51/7.1)
id AA21006; Fri, 25 Aug 89 08:40:41 PDT
Received: by tekchips.LABS.TEK.COM (5.51/6.24)
id AA15105; Fri, 25 Aug 89 08:43:10 PDT
Date: Fri, 25 Aug 89 08:43:10 PDT
From: Norman Adams <adams%tekchips.labs.tek.com@relay.cs.net>
Message-Id: <8908251543.AA15105@tekchips.LABS.TEK.COM>
To: RRRS-Authors@zurich.ai.mit.edu
Subject: Programmer-defined data types
This is a resend - I don't think I have seen this message come through
Date: Mon, 21 Aug 89 15:48:14 PDT
From: Norman Adams <adams%tekchips.labs.tek.com@relay.cs.net>
Message-Id: <8908212248.AA18203@tekchips.LABS.TEK.COM>
To: RRRS-Authors@zurich.ai.mit.edu
Cc: Pavel.pa@xerox.com
Subject: Programmer-defined data types
I support Pavel's proposal for records.
I would prefer that each abstraction-breaking procedure is identified as
such in its description. I prefer the term "field" to "slot."
-- Should there be a RECORD-COPIER procedure? Some folks would like to
have one for performance and convenience..
I can think of many operations generic to records. I don't think
copying deserves to be a special case.
-Norman
In addition, I concur with Alan's preference for a second argument
(a list of field names) to RECORD-CONSTRUCTOR.
∂26-Aug-89 0315 @mc.lcs.mit.edu,@life.ai.mit.edu:KMP@stony-brook.scrc.symbolics.com Programmer-defined data types
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 26 Aug 89 03:15:25 PDT
Received: from MINTAKA.LCS.MIT.EDU by life.ai.mit.edu (4.1/AI-4.10) id AB00962; Sat, 26 Aug 89 06:01:33 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa17208;
25 Aug 89 13:23 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 25 Aug 89 13:23:08 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa17188;
25 Aug 89 13:21 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA05011; Fri, 25 Aug 89 13:21:12 EDT
Received: from STONY-BROOK.SCRC.Symbolics.COM (stony-brook.scrc.symbolics.com) by zurich.ai.mit.edu; Fri, 25 Aug 89 13:16:56 edt
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 647383; 25 Aug 89 12:39:51 EDT
Date: Fri, 25 Aug 89 12:39 EDT
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Subject: Programmer-defined data types
To: cph@zurich.ai.mit.edu
Cc: bawden.pa@xerox.com, Pavel.pa@xerox.com, RRRS-Authors@zurich.ai.mit.edu,
KMP@stony-brook.scrc.symbolics.com
In-Reply-To: <8908241555.AA11386@zurich.ai.mit.edu>
Message-Id: <19890825163937.0.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Thu, 24 Aug 89 11:55:21 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
Date: Mon, 21 Aug 89 11:34 PDT
From: bawden.pa@xerox.com
Line-Fold: no
Date: Fri, 18 Aug 89 18:36:26 PDT
From: Pavel.pa@Xerox.COM
(RECORD-CONSTRUCTOR rtd)
Returns a procedure for constructing new members of the type represented by
rtd. The returned procedure accepts exactly as many arguments as there
were slot-names in the call to MAKE-RECORD-TYPE that created the type
represented by rtd; these are used, in order, as the initial values of
those slots in a new record, which is returned by the constructor
procedure.
I prefer the alternative that someone (RRJ?) made the last time we
discussed this:
(RECORD-CONSTRUCTOR rtd slot-names)
Where slot-names is a subset of the slot-names given to MAKE-RECORD-TYPE.
The returned procedure accepts exactly as many arguments as there are
slot-names. It creates a new record and initializes the specified slots.
I agree with this wholeheartedly. I think this form of the
constructor-constructor is significantly more useful. ...
I think you might want to allow a way to initialize the other arguments.
There are several ways you might want to do this, depending on how many
cases you want to handle and how convenient you want them to be:
- If you want to say initial values can't depend on one another, an
alist suffices. e.g.,
(DEFINE FOO (MAKE-RECORD-TYPE 'FOO '(A B C D)))
(DEFINE MAKE-FOO (RECORD-CONSTRUCTOR FOO '(A B C) '((D 0))))
- If you want to say initial values can depend on one another, but
beyond that, there are no ongoing constraints...
(DEFINE PERSON (MAKE-RECORD-TYPE 'PERSON '(HAIR-COLOR EYE-COLOR)))
(DEFINE HAIR-COLOR (RECORD-ACCESSOR PERSON 'HAIR-COLOR))
(DEFINE SET-HAIR-COLOR (RECORD-UPDATER PERSON 'HAIR-COLOR))
(DEFINE EYE-COLOR (RECORD-ACCESSOR PERSON 'EYE-COLOR))
(DEFINE SET-EYE-COLOR (RECORD-UPDATER PERSON 'EYE-COLOR))
(DEFINE MAKE-PERSON
(RECORD-CONSTRUCTOR
PERSON '(HAIR-COLOR)
(LAMBDA (PERSON)
(IF (MEMQ (HAIR-COLOR PERSON) '(BROWN BLACK))
(SET-EYE-COLOR PERSON 'BROWN)
(SET-EYE-COLOR PERSON 'BLUE)))))
- If you want to say initial values can depend on one another on
an ongoing basis, you have to extend the formalism further somehow.
To explain this, I'll show you a buggy example and you can ponder
how to fix it...
(DEFINE POSITION
(MAKE-RECORD-TYPE 'POSITION '(X Y Z CACHED-DISTANCE-FROM-ORIGIN)))
(DEFINE X-POSITION (RECORD-ACCESSOR POSITION 'X))
(DEFINE SET-X-POSITION (RECORD-UPDATER POSITION 'X))
(DEFINE Y-POSITION (RECORD-ACCESSOR POSITION 'Y))
(DEFINE SET-Y-POSITION (RECORD-UPDATER POSITION 'Y))
(DEFINE Z-POSITION (RECORD-ACCESSOR POSITION 'Z))
(DEFINE SET-Z-POSITION (RECORD-UPDATER POSITION 'Z))
(DEFINE DISTANCE-FROM-ORIGIN
(RECORD-ACCESSOR POSITION 'CACHED-DISTANCE-FROM-ORIGIN))
(DEFINE SET-DISTANCE-FROM-ORIGIN
(RECORD-UPDATER POSITION 'CACHED-DISTANCE-FROM-ORIGIN))
(DEFINE (UPDATE-DISTANCE-FROM-ORIGIN RECORD)
(SET-DISTANCE-FROM-ORIGIN
RECORD (SQRT (EXPT (X-POSITION RECORD) 2)
(EXPT (Y-POSITION RECORD) 2)
(EXPT (Z-POSITION RECORD) 2))))
(DEFINE MAKE-POSITION
(RECORD-CONSTRUCTOR POSITION '(X Y Z)
UPDATE-DISTANCE-FROM-ORIGIN))
The problem here is that every time you want to update X-, Y-, or
Z-POSITION, you will have to update CACHED-DISTANCE-FROM-ORIGIN and
there's no way to say that. A possible fix would be to generalize
RECORD-UPDATER to take a similar argument, which was run to make any
updates to `hidden' slots after the main assignment was done. If
you did this, though, it would be necessary to generalize RECORD-UPDATER
to take a list of slot names, rather than a single slot, so that the
function didn't get run multiple times when you were trying to update
several slots in parallel. e.g.,
(RECORD-UPDATER '(X Y Z) UPDATE-DISTANCE-FROM-ORIGIN)
would return you a function of four arguments, a record and new
values for X, Y and Z. Every time you called it, it would not only
set the values but would run the function which updated the hidden
slot.
This use of a function to run after assignment has been done is very
common in Flavors, by the way. Of course, there it's done as part of
a more general mechanism that no one is proposing here. But this simple
level of functionality offers an important hook that can be very powerful.
And it doesn't cost anyone anything if they're not using it.
Btw, if you change RECORD-UPDATER to require (or permit) a list, you
might want to make an analogous change to RECORD-ACCESSOR. In which
case multiple values are the likely thing to want to return.
[Now you can talk about this record stuff without feeling like you're
interrupting the multiple values discussion. :-]
If you do, then you're short a piece of language glue. Consider uses
like:
;Apparent idiom for copying slots from RECORD1 to RECORD2
(LAMBDA (RECORD1 RECORD2)
(WITH-VALUES
((RECORD-ACESSOR POSITION '(X Y Z)) RECORD2) ;returns 3 values
(LAMBDA (NEW-X NEW-Y NEW-Z)
((RECORD-UPDATER POSITION '(X Y Z)) RECORD1 NEW-X NEW-Y NEW-Z))))
There is too much gratuitous glue needed to stick this together, which is
an indictment of WITH-VALUES, if you ask me. I'll show how
COMPOSE-CONTINUATION could generalize to solve the problem, and then return
to why WITH-VALUES isn't so good. Suppose we permit:
(COMPOSE-CONTINUATION receiver arg1 ... argN generator)
where arg1...argN were something to interpose in the values stream, permitting
me to write:
(COMPOSE-CONTINUATION CONS 1 (LAMBDA () 2)) => (1 . 2)
Getting back to the example, I could write the above idiom as:
(LAMBDA (RECORD1 RECORD2)
(COMPOSE-CONTINUATION
(RECORD-UPDATER POSITION '(X Y Z))
RECORD2
((RECORD-ACESSOR POSITION '(X Y Z)) RECORD1)))
Personally, i think this feels about as good as it could be. Certainly I see
no wasted words, and the language glue permits the multi-valued functions to
snap together as they need to--an important property of language glue.
The proposed WITH-VALUES primitive doesn't seem to give me similar control.
The only `syntactic room' for extra arguments in WITH-VALUES is after the first
two arguments, so I would have to extend it as
(WITH-VALUES generator receiver arg1 arg2 ...)
which would mean that the interposed argument, RECORD, would not be in the
same order as it would appear in the values stream, writing the same idiom
from above as:
(LAMBDA (RECORD1 RECORD2)
(WITH-VALUES
((RECORD-ACESSOR POSITION '(X Y Z)) RECORD1)
(RECORD-UPDATER POSITION '(X Y Z))
RECORD2))
or it would mean that the updater needed to be changed to takes its RECORD
argument last. I don't like either of these solutions. And I do think the
need to interpose new items into the data-flow path is a common one (that
correctly led to the generalization of APPLY from a 2-argument function in
Maclisp to a multi-arg function in Common Lisp), so I think it's something
the designers of WITH-VALUES would do well to think carefully about.
∂26-Aug-89 0529 @mc.lcs.mit.edu:harrison@s45.csrd.uiuc.edu Numbers and Pork Rinds
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 26 Aug 89 05:29:49 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA01884; Sat, 26 Aug 89 08:05:28 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa17514;
25 Aug 89 13:52 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 25 Aug 89 13:52:44 EDT
Received: from [128.174.132.2] by mintaka.lcs.mit.edu id aa17279;
25 Aug 89 13:30 EDT
Received: from s45.csrd.uiuc.edu by uicsrd.csrd.uiuc.edu with SMTP
(5.61+/IDA-1.2.8) id AA20309; Fri, 25 Aug 89 12:30:43 -0500
Received: by s45.csrd.uiuc.edu (3.2/9.2)
id AA19968; Fri, 25 Aug 89 10:30:39 PDT
Date: Fri, 25 Aug 89 10:30:39 PDT
From: Luddy Harrison <harrison@s45.csrd.uiuc.edu>
Message-Id: <8908251730.AA19968@s45.csrd.uiuc.edu>
To: gls@think.com
Cc: bawden.pa@xerox.com, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Guy Steele's message of Thu, 24 Aug 89 12:28:42 EDT <8908241628.AA00798@verdi.think.com>
Subject: Numbers and Pork Rinds
>Hey, all you out there: does anyone else care? Has anyone's mind been
>changed as a result of our discussion?
Yes. I have but a minor comment to make. Alan, the inexactness you
attribute to floating point numbers is not a property of the
representation itself, but rather its interpretation (as a projection
of the space of real values). I, knowing the algebra of a floating
point implementation, may certainly write down an "exact" computation
in terms of floating point values. For example: (+ 2.0 3.0). Knowing
that by 2.0 and 3.0 I mean exactly 2 and 3, and knowing
the floating point unit of my machine, I know that the 5.0 that
results will be an "exact" result.
By the same token, I may write down an "inexact" computation in
terms of integers. For example, let H be a procedure that
heuristically evaluates a chess position and returns an integer
representing the goodness of the position. I interpret H's return
value as an interval, a distribution, around the "real" goodness of
the board. Now, when I write (max (H board-1) (H board-2)), I don't
expect max to understand that its arguments are grossly lacking in
precision. Neither would I expect it to do so if H returned a
floating point value. It is my job to determine the MEANING of the
representations I ask the computer to manipulate; I want only for the
computer to act predicatably upon the representations. Predictably,
in the case of floating point values, has traditionally meant that the
computer behaves as though the values were exact.
-Luddy Harrison
∂26-Aug-89 0532 @mc.lcs.mit.edu,@hp-sde.sde.hp.com:jinx@hpesogg.hp.com Numbers
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 26 Aug 89 05:31:59 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA01892; Sat, 26 Aug 89 08:08:58 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa18900;
25 Aug 89 15:36 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 25 Aug 89 15:36:23 EDT
Received: from hp-sde.sde.hp.com by mintaka.lcs.mit.edu id aa18864;
25 Aug 89 15:33 EDT
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA29730; Thu, 24 Aug 89 11:36:29 pdt
Message-Id: <8908241836.AA29730@sde.hp.com>
Received: by hpesogg; Thu, 24 Aug 89 11:35:48 pdt
Date: Thu, 24 Aug 89 11:35:48 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: bawden.pa@xerox.com
Cc: gls@think.com, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: bawden.pa@xerox.com's message of Mon, 21 Aug 89 17:24 PDT <19890822002405.2.ALAN@ROCKY.parc.xerox.com>
Subject: Numbers
Reply-To: jinx%hpesogg@sde.hp.com
Now I'm sure that about half of you are shouting at your terminal about how
I couldn't -possibly- mean that, but I do. Understand me once and for all:
INEXACT NUMBERS ARE NOT NUMBERS
INEXACT NUMBERS ARE NOT NUMBERS
INEXACT NUMBERS ARE NOT NUMBERS
They do not obey the rules followed by numbers, because they cannot.
Inexact numbers only represent our -approximate- -knowledge- about numbers.
In
(max 1.0 549755813889) ==> 549755813888.0
we strongly suspect that the first number is 1, but we don't know for sure.
Thus we strongly suspect that the answer is 549755813889, but again we
don't know for sure (the first number could have actually been
549755813890). Since we don't know the answer for sure, we must return an
inexact representation of our best guess. 549755813888.0 is the closest we
can come. (The next larger might be 549755879424.0, assuming 23 bits of
floating point precision, which is not very close at all.)
I'd rather see SUP/MAX reutrn the larger answer, than the numerically
closer answer. I use MAX rarely, and I think I've always intended it
to mean "something no smaller than any of its arguments".
Indeed, we could -specify- that MAX always ``round up'' in the inexact case
so that the result always appears greater (accroding to `<') than any of
the arguments. This would be similar to specifying that `<' must always
behave transitively. It would be a feeble attempt on our part to paper
over the ugly fact that -in- -general-, inexact numbers do not obey the
axioms of arithmetic.
However feeble, it would provide for a somewhat more intuitive and
predictable model. In the absence of detailed information about the
representation(s) of inexact numbers in a given implementation, and
the rounding algorithms using by min/max, I can't expect anything in
particular about the result value using your (and Will's) model.
Using the feeble constraint, I can at least bound the result.
∂27-Aug-89 0028 @mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu Multiple values for R4RS
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 27 Aug 89 00:28:36 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA00280; Sun, 27 Aug 89 03:14:24 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa01990;
26 Aug 89 18:01 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 26 Aug 89 17:44:23 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa24285;
26 Aug 89 0:20 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA12480; Sat, 26 Aug 89 00:20:08 EDT
Received: from skinner.cs.uoregon.edu ([128.223.4.13]) by zurich.ai.mit.edu; Sat, 26 Aug 89 00:16:51 edt
Received: from spencer.cs.uoregon.edu by skinner.cs.uoregon.edu with SMTP
(5.59++/IDA-1.2.8) id AA03202; Fri, 25 Aug 89 21:18:36 PDT
Received: by spencer.cs.uoregon.edu; Fri, 25 Aug 89 21:18:22 PDT
Date: Fri, 25 Aug 89 21:18:22 PDT
From: will@cs.uoregon.edu
Message-Id: <8908260418.AA19329@spencer.cs.uoregon.edu>
To: rrrs-authors@zurich.ai.mit.edu
Subject: Multiple values for R4RS
Cc: dyb@iuvax.cs.indiana.edu
Permit me a few remarks on how the Scheme reports have said what is
best left unsaid, and then I will explain why it is important to me
that (VALUES E) be the same as E.
Bill Rozas:
Undefined is fine with me. I previously suggested the possibility of
phrasing it as an implementation restriction. That would also be
fine.
What you want to say is that "the effect is unspecified" or (speaking
of a procedure) "its behavior is implementation dependent". For
examples of both, see the description of WITH-INPUT-FROM-FILE.
"Undefined" is bad because it has a definite meaning in Scheme: if the
value of a variable is undefined, then it is an error to reference that
variable. The use of undefined as an actual value is explicit in section
7.2 and is almost explicit in section 7.3. "Implementation restrictions"
are discouraged, which may be the effect you want in this case but would
not be likely to make your political opponent(s) happy.
Kent Pitman:
The net result for Common Lisp was that the old CLtL "is an error"
terminology will be replaced in ANSI CL by a whole bunch of new terms,
which cover the same turf in more refined fashion....I could pass along
the current draft meanings of those terms if anyone on Scheme was
serious about establishing some more refined error terminology.
I looked at the new CL terminology and decided not to use it, though
I added the notion of an implementation restriction.
I don't think a more refined error terminology would help us much.
In the last couple of days I've read about ten messages debating
Returning zero values or more than one value to something other
than a receiving procedure is an error.
versus something like
The effect of returning zero values or more than one value to
something other than a receiving procedure is unspecified.
when the real sticking point, as I see it, is the one-value case:
Kent Dybvig:
As an implementor, I would like to signal an error whenever someone
attempts to return (values ...) to a context where multiple values
aren't expected, or something other than (values ...) to a context
expecting multiple values. Requiring "(values e)" to be the same as
"e" makes it impossible to do this. As you pointed out in your note,
this won't affect anyone who doesn't like this behavior, since they
can always create their own versions of "values" and "with-values"
that circumvent the error checks.
The reason I don't like a semantics in which (VALUES E) is not required
to be the same as E doesn't have anything to do with whether I can
implement the semantics I like (I can, regardless). It has a little bit
to do with whether I can write certain portable programs (see example
below), but not much. It mainly has to do with the complexity of Scheme
considered as a programming language independent of its implementations.
The only way that I can see to understand or explain a semantics in
which (VALUES E) is not required to be the same as E is to postulate
an entirely new kind of object whose sole purpose is to communicate
between VALUES and receivers of multiple values. I then have to say
that the effect is undefined (or an error) if this new kind of object
ever gets passed to an ordinary continuation, procedure, or special
form (e.g. IF). That's a considerable amount of intellectual overhead
if the only reason for it is to allow some particular implementation
"to signal an error whenever someone attempts to return (VALUES ...)
to a context where multiple values aren't expected, or something other
than (VALUES ...) to a context expecting multiple values".
I think anyone who wants to impose this extra semantic complexity on
Scheme as the price for multiple values ought to explain why it is so
desirable for an implementation to signal an error in the circumstances
just described.
Here's an example of a potentially useful procedure that would be
less useful if (VALUES E) is not required to be the same as E:
; Given two procedures F and G, COMPOSE returns a procedure that
; acts as the composition of F and G. The arguments to F consist
; of all the values returned by G.
(define (compose f g)
(lambda args
(receive-values (lambda () (apply g args))
(lambda results (apply f results)))))
(define h1 (compose (lambda (x) (+ x 1)) *))
(h1 3 4) ==> 13
(define h2 (compose + (lambda (x y) (values (* 2 x) (+ y 1)))))
(h2 3 4) ==> 11
Kent Dybvig:
And this is the feature I'm most critical of. Unless an implementation
does support the truncation feature, I don't see any reason why we should
require that "(values e)" be equivalent to "e". I would like to feel
free to signal an error if "(values e)" is returned to a context that
is not prepared to accept multiple values.
I have given two reasons in this message, both of which are independent
of the truncation feature. I'm curious to know what you think of them,
and even more curious to know why signalling that error is so important
to you.
Incidentally, the proposed ACCEPTS? procedure also complicates the
language (because the denotations of procedures would have to carry
their arity), but the complication is fairly slight and the claimed
benefit is clearer. It is my impression that the benefit is about
as meager as the complication, but at least I understand the argument.
Also incidentally, the people who have been explaining how easy it
is to implement ACCEPTS? seem to have been assuming that the Scheme
implementor has control over the calling sequences and/or compilers.
It's not so easy if your goal is to build a Scheme system that uses
standard calling sequences and can call separately compiled C code
(say) without having to interpose a trampoline or other crock. That's
hard enough without having to define ACCEPTS? for unknown C procedures.
Peace, Will
∂27-Aug-89 1443 @mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu last call for MIN and MAX
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 27 Aug 89 14:42:53 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA03464; Sun, 27 Aug 89 17:24:11 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa01993;
26 Aug 89 18:02 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 26 Aug 89 17:44:30 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa24289;
26 Aug 89 0:20 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA12483; Sat, 26 Aug 89 00:20:22 EDT
Received: from skinner.cs.uoregon.edu ([128.223.4.13]) by zurich.ai.mit.edu; Sat, 26 Aug 89 00:17:06 edt
Received: from spencer.cs.uoregon.edu by skinner.cs.uoregon.edu with SMTP
(5.59++/IDA-1.2.8) id AB03203; Fri, 25 Aug 89 21:19:53 PDT
Received: by spencer.cs.uoregon.edu; Fri, 25 Aug 89 21:19:45 PDT
Date: Fri, 25 Aug 89 21:19:45 PDT
From: will@cs.uoregon.edu
Message-Id: <8908260419.AA19333@spencer.cs.uoregon.edu>
To: rrrs-authors@zurich.ai.mit.edu
Subject: last call for MIN and MAX
Guy "I Haven't Had So Much Fun While Trying to Be Serious in Years" Steele:
....I think that
when you speak of "exactness-preserving" you mean "inexactness-preserving",
and similarly "perfect rules of exactness" => "perfect rules of
inexactness" which is then seen to be a contradiction in terms.
That just goes to show that a contradiction in terms isn't the same
as a contradiction. Exact numbers are like original works of art;
they're not worth much unless they can be distinguished from forgeries.
Inexactness-preserving procedures, which stamp potential forgeries,
are the primary means for preserving the worth of exact numbers.
They're not perfect, because of the predicates and INEXACT->EXACT.
Despite its occasionally apocalyptic tone, this whole argument has been
about whether the pathologies inherent in an inexactness-preserving MIN
and MAX justify adding two more loopholes.
I think everyone who wants to understand this issue probably does by now,
and I assume that anyone who hasn't voted doesn't care.
Peace, Will
∂27-Aug-89 1647 @mc.lcs.mit.edu,@hp-sde.sde.hp.com:jinx@hpesogg.hp.com Numbers and Pork Rinds
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 27 Aug 89 16:47:21 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA04395; Sun, 27 Aug 89 19:36:13 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa03119;
26 Aug 89 19:54 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 26 Aug 89 19:52:13 EDT
Received: from hp-sde.sde.hp.com by mintaka.lcs.mit.edu id aa25737;
26 Aug 89 3:24 EDT
Received: from hpesogr.cup.hp.com by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA22725; Sat, 26 Aug 89 00:23:13 pdt
Message-Id: <8908260723.AA22725@sde.hp.com>
Received: by hpesogg; Sat, 26 Aug 89 00:22:29 pdt
Date: Sat, 26 Aug 89 00:22:29 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: bawden.pa@xerox.com
Cc: gls@think.com, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: bawden.pa@xerox.com's message of Thu, 24 Aug 89 17:37 PDT <19890825003740.7.ALAN@ROCKY.parc.xerox.com>
Subject: Numbers and Pork Rinds
Reply-To: jinx%hpesogg@sde.hp.com
But I think I am about to run out of steam. Alan and I have aired
our views pretty thoroughly, tying up a lot of mailboxes in the process.
Hey, all you out there: does anyone else care? Has anyone's mind been
changed as a result of our discussion?
Some of us have been mostly quiet because Alan has been doing a good
job of representing what we've come to accept (I argued fiercely
against Alan's/Will's notion of MIN and MAX a few months ago at MIT,
but I saw the light later).
The only additional constraint that I would like to see is that
SUP/MAX round up and INF/MIN round down when the relevant extreme is
exact, the implementation cannot determine that an exact answer is
correct, and thus the returned answer must be inexact.
Since (by Alan's argument) it is not correct for SUP/MAX to return the
exact argument (except in those implementations that can prove that
the exact answer is in fact the SUP/MAX), we cannot expect that the
answer will always be = to one of the arguments. We can, however,
still provide an answer that is guaranteed to be no smaller. Hence
the constraint.
I'll bet most people haven't been paying attention. I fully expect to have
to repeat this entire argument every six months for the rest of my life.
No. Hopefully the archives will still be around, and you can just
mail the whole discussion. Perhaps if they make it through it they
deserve to discuss it with you.
∂27-Aug-89 1653 @mc.lcs.mit.edu:bawden@arisia.xerox.com Numbers and Pork Rinds
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 27 Aug 89 16:53:11 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA04408; Sun, 27 Aug 89 19:41:34 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa12795;
27 Aug 89 17:42 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 27 Aug 89 17:41:43 EDT
Received: from [13.1.100.206] by mintaka.lcs.mit.edu id aa12734;
27 Aug 89 17:34 EDT
Received: from roo.parc.Xerox.COM by arisia.xerox.com with SMTP
(5.61+/IDA-1.2.8/gandalf) id AA02136; Sun, 27 Aug 89 14:29:25 -0700
Received: from mr-bun.parc.Xerox.COM by roo.parc.xerox.com with SMTP
(5.61+/IDA-1.2.8/gandalf) id AA06045; Sun, 27 Aug 89 14:31:55 PDT
Date: Sun, 27 Aug 89 14:30 PDT
From: Alan Bawden <bawden@arisia.xerox.com>
Subject: Numbers and Pork Rinds
To: harrison@s45.csrd.uiuc.edu
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: <8908251730.AA19968@s45.csrd.uiuc.edu>
Message-Id: <19890827213042.4.ALAN@MR-BUN.parc.xerox.com>
Date: Fri, 25 Aug 89 10:30:39 PDT
From: harrison@s45.csrd.uiuc.edu (Luddy Harrison)
... I have but a minor comment to make. Alan, the inexactness you
attribute to floating point numbers is not a property of the
representation itself, but rather its interpretation (as a projection
of the space of real values).
No, I don't myself "attribute" inexactness to floating point numbers at
all. In the context of the current discussion, the notion of an "inexact"
number has a purely technical meaning. An inexact number is a Scheme
object that the predicate INEXACT? is true of. It just so happens that the
most common technique for implementing inexact numbers is to use a floating
point representation (and not to use floating point for anything else), and
so in most Scheme implementations the two notions coincide.
This need not be the case.
Floating point numbers can be used as a representation for exact (rational)
numbers as well, if an implementation chooses. But since the set of
rationals represented exactly by floating point is not even approximately
closed under even the most common operations (consider (/ 1 3) or
(+ 1 1000000000000000000000000000000)), this doesn't seem to be a viable
choice.
Better is to play the game the other way, and use representations usually
used for exact numbers to represent inexact numbers. For example, A
convincing case can be made for using ratios to do inexact arithmetic.
(See the paper by Berthold Horn that describes this [an MIT AI Memo, I
think, I don't have my copy here].)
I, knowing the algebra of a floating
point implementation, may certainly write down an "exact" computation
in terms of floating point values. For example: (+ 2.0 3.0). Knowing
that by 2.0 and 3.0 I mean exactly 2 and 3, and knowing
the floating point unit of my machine, I know that the 5.0 that
results will be an "exact" result.
By the same token, I may write down an "inexact" computation in
terms of integers. For example, let H be a procedure that
heuristically evaluates a chess position and returns an integer
representing the goodness of the position. I interpret H's return
value as an interval, a distribution, around the "real" goodness of
the board. Now, when I write (max (H board-1) (H board-2)), I don't
expect max to understand that its arguments are grossly lacking in
precision. Neither would I expect it to do so if H returned a
floating point value.
This is all true, but doesn't address the issue of what happens if you
actually write a Scheme program to perform the computations you describe, and
then apply the predicates EXACT? and INEXACT? to the various Scheme objects
being manipulated. The "inexact" measure of the goodness of a particular
chess position may well be represented by a Scheme number that EXACT? is
true of. If you try and make the two notions of "exactness" coincide -- so
that INEXACT? will be true of all numbers that you know have a heuristic
derivation -- then most Scheme implementations will force you to be working
with floating point numbers.
It is my job to determine the MEANING of the
representations I ask the computer to manipulate; I want only for the
computer to act predicatably upon the representations. Predictably,
in the case of floating point values, has traditionally meant that the
computer behaves as though the values were exact.
On the machine I am using right now:
(/ 1.0 3.0) ==> 0.3333333432674407958984375
I suppose there is some sense in which this is "behaving as though the
values were exact". The value returned is in fact a -particular- rational
number. (It normally prints as "0.33333334" -- I have shown it here
printed precisely.) But it is not the -same- rational number that would be
returned in a different Scheme implementation, and it is not the same
rational number that a mathematician would compute with pencil and paper.
The sense of "inexact" that Scheme implements with its INEXACT? and EXACT?
predicates is that an exact number is an object that represents a
particular number, and that number was computed in such a way that the
implementation is certain that the -same- particular number would be
computed in any other implementation. The user can allow this condition to
become violated if he uses the procedure INEXACT->EXACT or any of the
numeric predicates. The current debate is about whether MAX and MIN also
allow this condition to become violated.
∂28-Aug-89 0455 ramsdell@linus.mitre.org Kent, please bless this multiple values proposal.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 28 Aug 89 04:55:35 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA01704; Mon, 28 Aug 89 07:35:33 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA02853; Mon, 28 Aug 89 07:36:17 EDT
Posted-Date: Mon, 28 Aug 89 07:30:00 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA16873; Mon, 28 Aug 89 07:30:02 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8908281130.AA16873@huxley.mitre.org>
To: dyb@iuvax.cs.indiana.edu
Cc: rrrs-authors@life.ai.mit.edu, ramsdell@linus.mitre.org
Subject: Kent, please bless this multiple values proposal.
In-Reply-To: Your message of Fri, 25 Aug 89 21:18:22 -0700.
<8908260418.AA19329@spencer.cs.uoregon.edu>
Date: Mon, 28 Aug 89 07:30:00 EDT
I believe I have a multiple values proposal acceptable to all. Given
the history of the Snowbird meeting, I ask you, Kent, to vote on this
proposal before I submit it to the rest of the authors. The essence
of the compromise is that we leave unspecified the effect of returning
zero values or more than one value to something other than a receiving
procedure. This means implementations may or may not signal an error
in this case, and both kinds of implementations are considered equally
correct. In an effort to reach compromise, others have given up their
requirement that some procedures such as ACCEPT? be included. In the
spirit of compromise, I hope you will give up your requirement that an
error may be signaled when a continuation expecting one value receives
one value from VALUEs.
John
--------------------------------
(values obj ...) essential procedure
Returns 0 or more values to a receiving procedure (See with-values).
(values) => returns zero (no) values
(values 1) => returns a single value, 1
(values 1 'a) => returns two values, 1 and the symbol a
Values applied to one argument simply returns its argument. The
effect of returning zero values or more than one value to something
other than a receiving procedure is unspecified.
(with-values generator receiver) essential procedure
Returns the result of applying the procedure 'receiver' to the values
produced by calling procedure 'generator' with no arguments. It is an
error if 'receiver' cannot be applied to the number of values returned
by 'generator' or if 'generator' cannot be called with zero arguments.
(with-values
(lambda ()
(values 1 2))
cons) => (1 . 2)
--------------------------------
∂28-Aug-89 0925 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #189
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 28 Aug 89 09:24:59 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA03736; Mon, 28 Aug 89 11:42:36 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa16013;
28 Aug 89 0:34 EDT
Date: 28 AUG 89 00:07:41 EDT
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.mc.lcs.edu>
Subject: Scheme Digest #189
To: Scheme%mc.lcs.mit.edu@mintaka.mc.lcs.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.mc.lcs.edu
Message-Id: <8908280034.aa16013@mintaka.lcs.mit.edu>
Scheme Digest #189 28 AUG 89 00:07:41 EDT
Today's Topics:
How Good Is Xscheme?
----------------------------------------------------------------------
Date: 27 Aug 89 03:36:54 GMT
From: "Roger R. Espinosa" <att!cbnewse!macduff@bloom-beacon.mit.edu>
Subject: How Good Is Xscheme?
Message-Id: <772@cbnewse.ATT.COM>
Hi.
I'm doing a project in scheme (Hi, Cordy!), and in the course
of trying to keep down the long-distance-modeming (since I'm
in Naperthrill, IL right now, and the *official* scheme is back
in Ann Arbor, MI...), I ftp'ed my way around and found two scheme
systems: xscheme v.0.16, and mit-scheme, version 7.0.
NOW ... the problem is that the copy of mit-scheme which I ftp'ed
onto the sun then onto the Macintosh and then onto the UTS feels that
the *.Z file is corrupted (I couldn't uncompress them on the sun before
putting them on the Mac for transportation because the system kept running
out of disk space). The Apollo felt the same way when I tried to uncompress
the original ftp'ed stuff from UM, which makes me wonder whether I'd
ever get mit-scheme running on the UTS to begin with.
BUT, xscheme transferred over and is presently running on the UTS here
in Naperville. It claims to be consistent with the Reivison↑3 report,
which is fine by me. How bugfree for *regular* schemeing is it? (I,
at the moment, am not interested in its object-oriented extensions.)
Please email all comments, advice, and guidelines to here, or to
att!ihlpn!rre (or rre@ihlpn.uucp).
Thanks!
Roger Espinosa
------------------------------
End of Scheme Digest
********************
∂28-Aug-89 1120 @mc.lcs.mit.edu:hieb@iuvax.cs.indiana.edu multiple values
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 28 Aug 89 11:20:41 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AB05289; Mon, 28 Aug 89 14:06:26 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa21930;
28 Aug 89 11:21 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 28 Aug 89 11:18:55 EDT
Received: from IUVAX.CS.INDIANA.EDU by mintaka.lcs.mit.edu id aa21840;
28 Aug 89 11:15 EDT
Received: by iuvax.cs.indiana.edu
Date: Mon, 28 Aug 89 10:15:32 -0500
From: Robert Hieb <hieb@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: multiple values
Message-Id: <8908281115.aa21840@mintaka.lcs.mit.edu>
I have avoided the mv debate, perhaps hoping nothing would come of it.
I worry whether mvs can be added to Scheme at this point without
"scabbing" them on (a carpenter's idiom, with obvious implications).
But John refuses to give up, and I sense the opposition is weakening.
So I enter at this late stage with a plea to "do it right."
I agree with Will's arguments for a semantics in which
e == (values e)
I also think we must be bold and call it an error whenever more or less than
one value is returned to a single-valued continuation. Otherwise, given the
wording of John's latest version, we are back precisely where Kent wanted us
all along!
From ramsdell@linus.mitre.org Mon Aug 28 06:45:56 1989
...The essence
of the compromise is that we leave unspecified the effect of returning
zero values or more than one value to something other than a receiving
procedure. This means implementations may or may not signal an error
in this case, and both kinds of implementations are considered equally
correct...
...It is an
error if 'receiver' cannot be applied to the number of values returned
by 'generator'...
This means, for instance, that
(with-values (lambda () (values 1 'a)) symbol?)
is an error, whereas
(symbol? (values 1 'a))
may be perfectly valid in some implementations (and for that matter,
may return #t).
As I understand it, the substance of Kent's argument all along was that
continuations produced by "with-values" should be distinct
from ordinary continuations, and "values" should be thought of as the
means of interacting with such continuations. On the other hand, the
opposition, with whom I thought myself allied, was arguing that continuations
produced by "with-values" differed only in arity from ordinary continuations.
It seems we are back to two kinds of continuations again.
Am I missing something?
Bob
∂28-Aug-89 1412 ramsdell@linus.mitre.org Re: multiple values
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 28 Aug 89 14:12:15 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA06956; Mon, 28 Aug 89 16:06:23 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA08366; Mon, 28 Aug 89 16:07:25 EDT
Posted-Date: Mon, 28 Aug 89 16:00:37 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA00462; Mon, 28 Aug 89 16:00:43 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8908282000.AA00462@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Subject: Re: multiple values
In-Reply-To: Your message of Mon, 28 Aug 89 10:15:32 -0500.
<8908281115.aa21840@mintaka.lcs.mit.edu>
Date: Mon, 28 Aug 89 16:00:37 EDT
>> From: Robert Hieb <hieb@iuvax.cs.indiana.edu>
...
>> As I understand it, the substance of Kent's argument all along was that
>> continuations produced by "with-values" should be distinct
>> from ordinary continuations, and "values" should be thought of as the
>> means of interacting with such continuations. On the other hand, the
>> opposition, with whom I thought myself allied, was arguing that continuations
>> produced by "with-values" differed only in arity from ordinary continuations.
>> It seems we are back to two kinds of continuations again.
>>
As I see it, the proposal implies that continuations produced by
WITH-VALUES differ only in arity from ordinary continuations. The
compromise is not to specify the arity of ordinary continuations.
Thus implimentations is which ordinary continuation can only be applied
to only exactly one value are just as valid as implementations which
allow ordinary continuations to be applied to one or more values. I
believe this proposal satisfies your requirements. Please tell me if
you are not convinced.
John
∂28-Aug-89 1619 bawden@arisia.xerox.com Re: multiple values
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 28 Aug 89 16:19:44 PDT
Received: from arisia.xerox.com by life.ai.mit.edu (4.1/AI-4.10) id AA09283; Mon, 28 Aug 89 19:00:39 EDT
Received: from roo.parc.Xerox.COM by arisia.xerox.com with SMTP
(5.61+/IDA-1.2.8/gandalf) id AA16474; Mon, 28 Aug 89 15:57:02 -0700
Received: from mr-bun.parc.Xerox.COM by roo.parc.xerox.com with SMTP
(5.61+/IDA-1.2.8/gandalf) id AA04287; Mon, 28 Aug 89 15:59:33 PDT
Date: Mon, 28 Aug 89 15:58 PDT
From: Alan Bawden <bawden@arisia.xerox.com>
Subject: Re: multiple values
To: ramsdell@linus.mitre.org
Cc: rrrs-authors@life.ai.mit.edu
In-Reply-To: <8908282000.AA00462@huxley.mitre.org>
Message-Id: <19890828225827.2.ALAN@MR-BUN.parc.xerox.com>
So is this a permissible implementation of your proposal? It seems to me
that it must be since you only try to specify what happens if other than
one value is returned to WITH-VALUES, and nowhere else.
(define magic-multiple-values-marker (list '* 'multiple 'values '*))
(define (values . vals)
(if (= 1 (length vals))
(car vals)
(cons magic-multiple-values-marker vals)))
(define (with-values thunk receive)
(let ((result (thunk)))
(if (and (pair? result)
(eq? (car result) magic-multiple-values-marker))
(apply receive (cdr result))
(receive result))))
∂28-Aug-89 1955 @mc.lcs.mit.edu,@gateway.think.com:gls@think.com Numbers and Pork Rinds
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 28 Aug 89 19:55:08 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA11042; Mon, 28 Aug 89 22:46:00 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22848;
28 Aug 89 12:40 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 28 Aug 89 12:40:40 EDT
Received: from Gateway.Think.COM by mintaka.lcs.mit.edu id aa22831;
28 Aug 89 12:37 EDT
Received: from fafnir.think.com by Think.COM; Mon, 28 Aug 89 12:38:53 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Mon, 28 Aug 89 12:36:07 EDT
Received: by verdi.think.com; Mon, 28 Aug 89 12:35:45 EDT
Date: Mon, 28 Aug 89 12:35:45 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8908281635.AA09595@verdi.think.com>
To: bawden@arisia.xerox.com
Cc: harrison@s45.csrd.uiuc.edu, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Alan Bawden's message of Sun, 27 Aug 89 14:30 PDT <19890827213042.4.ALAN@MR-BUN.parc.xerox.com>
Subject: Numbers and Pork Rinds
Date: Sun, 27 Aug 89 14:30 PDT
From: Alan Bawden <bawden@arisia.xerox.com>
Floating point numbers can be used as a representation for exact (rational)
numbers as well, if an implementation chooses. But since the set of
rationals represented exactly by floating point is not even approximately
closed under even the most common operations (consider (/ 1 3) or
(+ 1 1000000000000000000000000000000)), this doesn't seem to be a viable
choice.
Actually, an implementation using IEEE arithmetic might find it completely
convenient to have both exact and inexact floats; a result float would be
exact if all inputs are exact AND the IEEE operation(s) reported no inexact
exception. (This is a minor point.)
--Guy
∂28-Aug-89 2212 @mc.lcs.mit.edu:bawden@arisia.xerox.com Numbers and Pork Rinds
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 28 Aug 89 22:12:50 PDT
Received: from MINTAKA.LCS.MIT.EDU by life.ai.mit.edu (4.1/AI-4.10) id AB13003; Tue, 29 Aug 89 01:01:19 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa24197;
28 Aug 89 14:42 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 28 Aug 89 14:41:11 EDT
Received: from arisia.Xerox.COM by mintaka.lcs.mit.edu id aa24188;
28 Aug 89 14:40 EDT
Received: from roo.parc.Xerox.COM by arisia.xerox.com with SMTP
(5.61+/IDA-1.2.8/gandalf) id AA12805; Mon, 28 Aug 89 11:36:25 -0700
Received: from mr-bun.parc.Xerox.COM by roo.parc.xerox.com with SMTP
(5.61+/IDA-1.2.8/gandalf) id AA02451; Mon, 28 Aug 89 11:38:57 PDT
Date: Mon, 28 Aug 89 11:37 PDT
From: Alan Bawden <bawden@arisia.xerox.com>
Subject: Numbers and Pork Rinds
To: gls@think.com
Cc: harrison@s45.csrd.uiuc.edu, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: <8908281635.AA09595@verdi.think.com>
Message-Id: <19890828183753.0.ALAN@MR-BUN.parc.xerox.com>
Date: Mon, 28 Aug 89 12:35:45 EDT
From: gls@Think.COM (Guy Steele)
... an implementation using IEEE arithmetic might find it completely
convenient to have both exact and inexact floats; a result float would be
exact if all inputs are exact AND the IEEE operation(s) reported no inexact
exception....
Quite right. With IEEE giving you this assistance you can even consider
using -only- IEEE floats in your Scheme implementation -- using them for
both exact and inexact numbers. This should give you an adequate range of
exact integers to index vectors and measure the lengths of lists (as well
as a random collection of exact rationals of the form M/(2↑N)). This might
even be a reasonable thing to do if you're trying to do a quick and simple
Scheme implementation. (But if your floating point hardware -doesn't- tell
you about loss of exactness, I can't imagine making such a choice.)
∂29-Aug-89 0050 @mc.lcs.mit.edu,@hp-sde.sde.hp.com:jinx@hpesogg.hp.com multiple values
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 29 Aug 89 00:49:50 PDT
Received: from MINTAKA.LCS.MIT.EDU by life.ai.mit.edu (4.1/AI-4.10) id AB00296; Tue, 29 Aug 89 03:10:33 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa27038;
28 Aug 89 18:22 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 28 Aug 89 18:22:59 EDT
Received: from hp-sde.sde.hp.com by mintaka.lcs.mit.edu id aa27028;
28 Aug 89 18:21 EDT
Received: from hpesogr.cup.hp.com by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA27617; Mon, 28 Aug 89 12:15:30 pdt
Message-Id: <8908281915.AA27617@sde.hp.com>
Received: by hpesogg; Mon, 28 Aug 89 12:14:47 pdt
Date: Mon, 28 Aug 89 12:14:47 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: hieb@iuvax.cs.indiana.edu
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Robert Hieb's message of Mon, 28 Aug 89 10:15:32 -0500 <8908281115.aa21840@mintaka.lcs.mit.edu>
Subject: multiple values
Reply-To: jinx%hpesogg@sde.hp.com
On the other hand, the
opposition, with whom I thought myself allied, was arguing that continuations
produced by "with-values" differed only in arity from ordinary
continuations.
Not quite. There are two issues at stake:
A) (values e) == e
B) Are implicit continuations modelled as
(lambda (value) ...)
or as
(lambda (value . ignore) ...)
I would like to see A hold true, and B adopt the latter solution.
This is impractical politically, so I will grudgingly accept B to be
left unspecified.
Issue A, if rejected, would force two kinds of continuations.
Issue B does not. It just determines (or fails to determine) the
arity of implicit continuations, but they are no different from
"explicit" continuations.
∂29-Aug-89 0517 ramsdell@linus.mitre.org Re: multiple values
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 29 Aug 89 05:17:03 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA01881; Tue, 29 Aug 89 07:59:28 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA24071; Tue, 29 Aug 89 08:00:03 EDT
Posted-Date: Tue, 29 Aug 89 07:53:19 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA01279; Tue, 29 Aug 89 07:53:20 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8908291153.AA01279@huxley.mitre.org>
To: Alan Bawden <bawden@arisia.xerox.com>
Cc: ramsdell@linus.mitre.org, rrrs-authors@life.ai.mit.edu
Subject: Re: multiple values
In-Reply-To: Your message of Mon, 28 Aug 89 15:58:00 -0700.
<19890828225827.2.ALAN@MR-BUN.parc.xerox.com>
Date: Tue, 29 Aug 89 07:53:19 EDT
>> From: Alan Bawden <bawden@arisia.xerox.com>
...
>> So is this a permissible implementation of your proposal? It seems to me
>> that it must be since you only try to specify what happens if other than
>> one value is returned to WITH-VALUES, and nowhere else.
>>
>> (define magic-multiple-values-marker (list '* 'multiple 'values '*))
>>
>> (define (values . vals)
>> (if (= 1 (length vals))
>> (car vals)
>> (cons magic-multiple-values-marker vals)))
>>
>> (define (with-values thunk receive)
>> (let ((result (thunk)))
>> (if (and (pair? result)
>> (eq? (car result) magic-multiple-values-marker))
>> (apply receive (cdr result))
>> (receive result))))
The above looks to me to be a legal implementation of the proposal.
Alan has shown the ease in which all Scheme implementations can
be modified so as to correctly implement multiple values. Of course,
programmers using quality implementations can expect much better code
to be generated from optimizing compilers.
Leaving the arity of ordinary continuations unspecified is a bit
unsettling, however, I believe it to be the only viable way of
reaching agreement on this subject. I hope this compromise will not
be the last word on the subject of multiple values, but a base on
which we build future agreements. Now is the time to crawl; only
later should we try to walk. Let's wait for Kent's words.
Don't panic,
John
∂29-Aug-89 0657 ramsdell@linus.mitre.org rrrs-authors-request@life.ai.mit.edu is broken.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 29 Aug 89 06:57:27 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA02523; Tue, 29 Aug 89 09:29:29 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA24831; Tue, 29 Aug 89 09:30:21 EDT
Posted-Date: Tue, 29 Aug 89 09:23:37 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA01417; Tue, 29 Aug 89 09:23:38 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8908291323.AA01417@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Subject: rrrs-authors-request@life.ai.mit.edu is broken.
Date: Tue, 29 Aug 89 09:23:37 EDT
rrrs-authors-request@life.ai.mit.edu is broken.
------- Forwarded Message
Return-Path: MAILER-DAEMON@sde.hp.com
Return-Path: <MAILER-DAEMON@sde.hp.com>
Received: from hp-sde.sde.hp.com by linus.MITRE.ORG (5.59/RCF-3S)
id AA24792; Tue, 29 Aug 89 09:28:45 EDT
Posted-Date: Tue, 29 Aug 89 09:20:58 EDT
Received: from hp-ses.sde.hp.com by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA23661; Tue, 29 Aug 89 06:27:25 pdt
Received: from sde.hp.com by hp-ses.sde.hp.com with SMTP
(15.7/SES42.42) id AA09554; Tue, 29 Aug 89 06:27:21 pdt
Date: Tue, 29 Aug 89 09:20:58 EDT
From: Mail Delivery Subsystem <MAILER-DAEMON@sde.hp.com>
Subject: Returned mail: unknown mailer error 101
Message-Id: <8908291327.AA09554@hp-ses.sde.hp.com>
To: <ramsdell@linus.MITRE.ORG>
----- Transcript of session follows -----
bad system name: hpesogg
uux failed. code 101
554 <jinx@hpesogg>... unknown mailer error 101
----- Unsent message follows -----
Received: from sde.hp.com by hp-ses.sde.hp.com with SMTP
(15.7/SES42.42) id AA09550; Tue, 29 Aug 89 06:27:21 pdt
Return-Path: <ramsdell@linus.mitre.org>
Received: from life.ai.mit.edu by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA23656; Tue, 29 Aug 89 06:27:15 pdt
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02511; Tue, 29 Aug 89 09:27:13 EDT
Received: from life.ai.mit.edu (life.ai.mit.edu) by zurich.ai.mit.edu; Tue, 29 Aug 89 09:24:00 edt
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA02508; Tue, 29 Aug 89 09:26:39 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA24785; Tue, 29 Aug 89 09:27:42 EDT
Posted-Date: Tue, 29 Aug 89 09:20:58 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA01407; Tue, 29 Aug 89 09:20:59 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8908291320.AA01407@huxley.mitre.org>
To: rrrs-authors-request@life.ai.mit.edu
Subject: rrrs-authors-request test.
Date: Tue, 29 Aug 89 09:20:58 EDT
Just a test.
------- End of Forwarded Message
∂29-Aug-89 0732 @mc.lcs.mit.edu,@hp-sde.sde.hp.com:jinx@hpesogg.hp.com Numbers and Pork Rinds
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 29 Aug 89 07:31:37 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA02912; Tue, 29 Aug 89 10:17:02 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa04537;
29 Aug 89 3:55 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 29 Aug 89 03:55:57 EDT
Received: from hp-sde.sde.hp.com by mintaka.lcs.mit.edu id aa04514;
29 Aug 89 3:54 EDT
Received: from hpesogr.cup.hp.com by hp-sde.sde.hp.com with SMTP
(15.7/SES42.42) id AA13335; Tue, 29 Aug 89 00:18:54 pdt
Message-Id: <8908290718.AA13335@sde.hp.com>
Received: by hpesogg; Tue, 29 Aug 89 00:16:49 pdt
Date: Tue, 29 Aug 89 00:16:49 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: gls@think.com
Cc: bawden@arisia.xerox.com, harrison@s45.csrd.uiuc.edu,
rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Guy Steele's message of Mon, 28 Aug 89 12:35:45 EDT <8908281635.AA09595@verdi.think.com>
Subject: Numbers and Pork Rinds
Reply-To: jinx%hpesogg@sde.hp.com
Actually, an implementation using IEEE arithmetic might find it completely
convenient to have both exact and inexact floats; a result float would be
exact if all inputs are exact AND the IEEE operation(s) reported no inexact
exception. (This is a minor point.)
This is where the notion of inexactness in fact came from. The
original idea was to have an orthogonal exactness bit for each
representation which the implementation would maintain correctly.
∂29-Aug-89 0838 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #188
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 29 Aug 89 08:38:18 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA03326; Tue, 29 Aug 89 10:58:53 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa01300;
26 Aug 89 17:11 EDT
Date: 26 AUG 89 16:38:46 EDT
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.mc.lcs.edu>
Subject: Scheme Digest #188
To: Scheme%mc.lcs.mit.edu@mintaka.mc.lcs.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.mc.lcs.edu
Message-Id: <8908261711.aa01300@mintaka.lcs.mit.edu>
Scheme Digest #188 26 AUG 89 16:38:46 EDT
Today's Topics:
Is there a version of xscheme later than 0.16?
OOPS system for Scheme - where?
X Scheme availability
----------------------------------------------------------------------
Date: 24 Aug 89 16:37:55 GMT
From: "Luiz H. deFigueiredo" <att!watmath!maytag!aries5!lhf@bloom-beacon.mit.edu>
Subject: Is there a version of xscheme later than 0.16?
Message-Id: <413@maytag.waterloo.edu>
Does anyone know about this?
Dave Betz, maybe?
-------------------------------------------------------------------------------
Luiz Henrique de Figueiredo internet: lhf@aries5.waterloo.edu
Computer Systems Group bitnet: lhf@watcsg
University of Waterloo (possible domains are waterloo.edu and uwaterloo.ca)
-------------------------------------------------------------------------------
------------------------------
Date: 25 Aug 89 17:32:22 GMT
From: Mark Biggers <rti!xyzzy!dg-rtp!biggers@mcnc.org>
Subject: OOPS system for Scheme - where?
Message-Id: <BIGGERS.89Aug25133222@zippy.dg-rtp.dg.com>
Howdy,
I would be very interested in public-domain or freely available
sources for an object system for Scheme, such as SCOOPS, or some
analog of CLOS for Scheme. Pointers, please?
thanks much,
mark
(news mail header is bogus; mail addresses below...)
--
↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑
biggers@dg-rtp.dg.com USMail: Data General
OR: rti!dg-rtp!biggers 62 Alexander Drive
Research Triangle Park, NC 27709
↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑
------------------------------
Date: 25 Aug 89 03:04:06 GMT
From: jdm <hodge!jdm@uunet.uu.net>
Subject: Re: X Scheme availability
Message-Id: <21650@hodge.UUCP>
>
> Is there a newer version? I'd like a copy too.
>
Not to long ago I downloaded Xscheme 0.17 from the Video 7 BBS (yes,
the VGA board people) at 415-656-0503 (12|2400,8,N,1).
--
"I'm an anthropologist, not a computer systems architect, damit!"
jdm@hodge.cts.com [uunet zardoz crash]!hodge!jdm
James D. Murray, Ethnounixologist TEL: (714) 998-7750 Ext. 129
Hodge Computer Research Corporation FAX: (714) 921-8038
1588 North Batavia Street
Orange, California 92667 USA
------------------------------
End of Scheme Digest
********************
∂29-Aug-89 0915 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #190
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 29 Aug 89 09:15:12 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA02557; Tue, 29 Aug 89 09:35:50 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa01591;
29 Aug 89 0:09 EDT
Date: 29 AUG 89 00:07:47 EDT
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.mc.lcs.edu>
Subject: Scheme Digest #190
To: Scheme%mc.lcs.mit.edu@mintaka.mc.lcs.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.mc.lcs.edu
Message-Id: <8908290009.aa01591@mintaka.lcs.mit.edu>
Scheme Digest #190 29 AUG 89 00:07:47 EDT
Today's Topics:
Scheme Digest #169
----------------------------------------------------------------------
Date: Mon, 28 Aug 89 21:08 CST
From: RKIRCHNE@carleton.edu
Subject: RE: Scheme Digest #169
Message-ID: <8908282205.aa29915@mintaka.lcs.mit.edu>
This is the last Scheme Digest I have. Our network has been down
for a couple of weeks. Could you have my name reactivated and send me
Digests 170- ? Thanks. Roger Kirchner
------------------------------
End of Scheme Digest
********************
∂29-Aug-89 1316 mkatz@sesame.stanford.edu Kent, please bless this multiple values proposal.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 29 Aug 89 13:13:27 PDT
Received: from sesame.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA06912; Tue, 29 Aug 89 15:52:59 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA00670; Tue, 29 Aug 89 12:51:36 PDT
Date: Tue, 29 Aug 89 12:51:36 PDT
From: mkatz@sesame.stanford.edu (Morris Katz)
Message-Id: <8908291951.AA00670@sesame.Stanford.EDU>
To: ramsdell@linus.mitre.org
Cc: dyb@iuvax.cs.indiana.edu, rrrs-authors@life.ai.mit.edu,
ramsdell@linus.mitre.org
In-Reply-To: ramsdell@linus.mitre.org's message of Mon, 28 Aug 89 07:30:00 EDT <8908281130.AA16873@huxley.mitre.org>
Subject: Kent, please bless this multiple values proposal.
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Posted-Date: Mon, 28 Aug 89 07:30:00 EDT
From: ramsdell@linus.mitre.org
Date: Mon, 28 Aug 89 07:30:00 EDT
I believe I have a multiple values proposal acceptable to all.
(values obj ...) essential procedure
...
The effect of returning zero values or more than one value to something
other than a receiving procedure is unspecified.
I believe that the sentence above leaves things a little too unspecified. In
particular, I believe that it is important that in the following code CONT
accept exactly two values.
(with-values
(call-with-current-continuation
(lambda (c)
(set! cont c)
(values 1 2)))
cons)
Similarly, any continuation captured with CALL-WITH-CURRENT-CONTINUATION which
tail recurses into the first argument position of WITH-VALUES should require
and exact arity match with the receiver.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂29-Aug-89 1920 @mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com Programmer-defined data types, version 2
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 29 Aug 89 19:20:05 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA10759; Tue, 29 Aug 89 22:01:18 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa09107;
29 Aug 89 21:54 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 29 Aug 89 21:54:58 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa09063;
29 Aug 89 21:52 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA10725; Tue, 29 Aug 89 21:52:27 EDT
Received: from Xerox.COM (xerox.com) by zurich.ai.mit.edu; Tue, 29 Aug 89 21:49:08 edt
Received: from Semillon.ms by ArpaGateway.ms ; 29 AUG 89 18:47:15 PDT
Date: Tue, 29 Aug 89 18:29:19 PDT
From: Pavel.pa@xerox.com
Subject: Programmer-defined data types, version 2
To: RRRS-Authors@zurich.ai.mit.edu
Cc: Pavel.pa@xerox.com
Message-Id: <890829-184715-4408@Xerox>
Several people either proposed or supported a proposal that
RECORD-CONSTRUCTOR take a second argument, being a list of the slots
initialized by the new constructor, in the order of the actual arguments to
the constructor. I support this change; it is reflected in the new version
of the proposal below.
In mail to the BASH list, Morry asked that this new second argument be
optional, defaulting to the relatively common case of all slots, in the
order specified in the call to MAKE-RECORD-TYPE. I think I agree with that
and can appreciate his dissatisfaction with the prospect of having to
repeat the entire list of names again. This modification of the above
proposal is also reflected below.
Kent Pitman (I wish others would be more specific when they quote ``Kent''
on this list; sometimes it's non-trivial to determine whether they're
talking about the ``Pitman'' or ``Dybvig'' flavor...) made a number of
suggestions concerning the default values of slots not initialized by a
constructor. This discussion extended into what amounted to an
active-value facility, with hooks provided for notification when slots are
read or written. My response is to say that it certainly seems as if such
facilities might be useful, but they are definitely beyond the scope of
this proposal. The intent here is simply to provide the raw facilities for
user-defined data types. Everything Kent suggests can be written in terms
of what's provided here and perhaps placed in the library; if they receive
widespread approval, perhaps we could later consider them for inclusion in
the language.
In a similar vein, Ziggy would like constructors to follow what amounts to
a Common Lisp keyword-style calling protocol, in which each slot value is
preceded in the argument list by the name of the slot. This would be
inconsistent with every other procedure currently in Scheme (CONS comes to
mind as the best example), so I am reluctant to add it here. Again, such a
facility could be implemented for the library.
Several people reported varying levels of nausea resulting from my use of
the term ``slot'' where, for example, ``field'' might have been less
traumatic. I have made the stomach-settling change in the proposal below.
I made a note that ``the type-name argument to MAKE-RECORD-TYPE is
constrained to be a string in order to allow experimentation with
interesting semantics for other kinds of values there. One possibility
raised in the discussion in 1988 was some kind of a `handler' procedure, as
in T objects.'' In reaction, Bawden commented, ``Even if someday you can
pass a ``handler'' to MAKE-RECORD-TYPE, mightn't you -also- want to pass a
type-name? I don't see how the two are exclusive.'' I believe this is
handled in T by having the handler deal with an operation that provides the
type-name. Thus, in such a system, passing a string would be equivalent to
passing a simple handler that only dealt with the fetch-type-name
operation. In any case, I don't have a strong opinion about this; it does
not appear that Alan does either, so I've left this part of the proposal
unchanged.
Alan was the only person to comment on the semantics of EQUAL? when applied
to records of the same type, expressing the opinion that EQUAL? should
behave like EQV? in such cases. I take others' silence on the point as
agreement and have so modified the proposal.
Norman would like to see all ``abstraction-breaking'' procedures so
identified in their description. I think that this classification could
well be a matter of opinion on which some authors may disagree. For the
time being, therefore, I have not followed up on this suggestion. I
welcome comments.
Norman expressed the only opinion on whether or not a RECORD-COPIER
procedure should exist; Norman feels that it should not, being just one of
several possible operations generic to records. I tend to agree and so
have removed the issue from the proposal.
Ziggy asked why, in the desciption of RECORD-TYPE-SLOT-NAMES, the returned
value is constrained to be EQUAL? to the list of names given to
MAKE-RECORD-TYPE. This is necessary in order to use RECORD-CONSTRUCTOR
properly; it must be possible to discover the order of arguments to
constructors. Of course, this is no longer necessary, since the given list
can now be passed as the second argument to RECORD-CONSTRUCTOR. I have
therefore rewritten the restriction, below, to imply only set-equality of
the two lists.
I think that this covers all of the responses I've received thus far. I'm
sure I'll hear about it if that's not the case... Here is the new version
of the proposal.
=====================
We propose adding the following procedures to Scheme:
(MAKE-RECORD-TYPE type-name field-names)
Returns a ``record-type descriptor'', a value representing a new data type,
disjoint from all others. The type-name argument must be a string, but is
only used for debugging purposes (such as the printed representation of a
record of the new type). The field-names argument is a list of symbols
naming the ``fields'' of a record of the new type. It is an error if the
list contains any duplicates.
(RECORD-CONSTRUCTOR rtd [field-names])
Returns a procedure for constructing new members of the type represented by
rtd. The returned procedure accepts exactly as many arguments as there are
symbols in the given list, field-names; these are used, in order, as the
initial values of those fields in a new record, which is returned by the
constructor procedure. The values of any fields not named in that list are
unspecified. The field-names argument defaults to the list of field-names
in the call to MAKE-RECORD-TYPE that created the type represented by rtd;
if the field-names argument is provided, it is an error if it contains any
duplicates or any symbols not in the default list.
(RECORD-PREDICATE rtd)
Returns a procedure for testing membership in the type represented by rtd.
The returned procedure accepts exactly one argument and returns a true
value if the argument is a member of the indicated record type; it returns
a false value otherwise.
(RECORD-ACCESSOR rtd field-name)
Returns a procedure for reading the value of a particular field of a member
of the type represented by rtd. The returned procedure accepts exactly one
argument which must be a record of the appropriate type; it returns the
current value of the field named by the symbol field-name in that record.
The symbol field-name must be a member of the list of field-names in the
call to MAKE-RECORD-TYPE that created the type represented by rtd.
(RECORD-UPDATER rtd field-name)
Returns a procedure for writing the value of a particular field of a member
of the type represented by rtd. The returned procedure accepts exactly two
arguments: a record of the appropriate type and an arbitrary Scheme value;
it modifies the field named by the symbol field-name in that record to
contain the given value. The returned value of the updater procedure is
unspecified. The symbol field-name must be a member of the list of
field-names in the call to MAKE-RECORD-TYPE that created the type
represented by rtd.
(RECORD? obj)
Returns a true value if obj is a record of any type and a false value
otherwise.
(RECORD-TYPE-DESCRIPTOR record)
Returns a record-type descriptor representing the type of the given record.
That is, for example, if the returned descriptor were passed to
RECORD-PREDICATE, the resulting predicate would return a true value when
passed the given record. Note that it is not necessarily the case that the
returned descriptor is the one that was passed to RECORD-CONSTRUCTOR in the
call that created the constructor procedure that created the given record.
(RECORD-TYPE-NAME rtd)
Returns the type-name associated with the type represented by rtd. The
returned value is EQV? to the type-name argument given in the call to
MAKE-RECORD-TYPE that created the type represented by rtd.
(RECORD-TYPE-FIELD-NAMES rtd)
Returns a list of the symbols naming the fields in members of the type
represented by rtd. The returned value contains precisely the set of
symbols in the field-names argument given in the call to MAKE-RECORD-TYPE
that created the type represented by rtd.
=====================
Notes on the proposal
=====================
-- The procedure RECORD? is necessary to allow reliable use of the
procedure RECORD-TYPE-DESCRIPTOR.
-- The type-name argument to MAKE-RECORD-TYPE is constrained to be a string
in order to allow experimentation with interesting semantics for other
kinds of values there. One possibility raised in the discussion in 1988
was some kind of a ``handler'' procedure, as in T objects.
-- We do not propose any general macro for the definition of record types.
The feeling is that this is not easy to do in a way that is both elegant
and sufficiently flexible. Once we have macros, the primitives above
should be sufficient for portable experimentation.
-- The issues of subtyping and inheritance, print methods, and integration
with modules and/or
environments (e.g. Pascal's WITH construct) have been purposely avoided in
order to achieve more rapid consensus. Designs for adding single
inheritance appeared in the discussion in 1988.
-- A case can be made that constructor procedures should take no arguments
and leave all fields in new records uninitialized. There appear to be
advantages to both points of view.
-- EQ? and EQV? treat records in the same way as they do pairs, vectors,
and strings. EQUAL? is equivalent to EQV? on records.
Pavel
∂30-Aug-89 0021 Pavel.pa@xerox.com Multiple values
Received: from life.ai.mit.edu ([128.52.32.80]) by SAIL.Stanford.EDU with TCP; 30 Aug 89 00:21:49 PDT
Received: from Xerox.COM by life.ai.mit.edu (4.1/AI-4.10) id AA00287; Wed, 30 Aug 89 03:05:04 EDT
Received: from Semillon.ms by ArpaGateway.ms ; 29 AUG 89 19:08:56 PDT
Date: Tue, 29 Aug 89 19:10:26 PDT
From: Pavel.pa@xerox.com
Subject: Multiple values
To: RRRS-Authors@life.ai.mit.edu
Cc: Pavel.pa@xerox.com
Message-Id: <890829-190856-4440@Xerox>
I essentially support the current multiple-values proposal, but I have a
few comments and suggested clarifications.
-- At BASH, we decided that what has been called WITH-VALUES would be
better named CALL-WITH-VALUES, to be consistent with CALL-WITH-INPUT-FILE.
I still agree with this, but wouldn't hold up progress if others were
strongly opposed to this name.
-- I am unhappy with the current description of VALUES, in particular with
the special casing of the single-argument case. Why not simply say that
VALUES returns all of its arguments? Alternatively, could we simply give
the simple implementation of VALUES in terms of CALL/CC?
(define values args
(call-with-current-continuation
(lambda (k)
(apply k args))))
This seems a lot more clear than what's there now.
-- I am similarly unhappy with the way in which the arity of continuations
is described. Allow me to suggest the following:
==========
There are six contexts in which continuations can be captured in Scheme:
* the operator position of a procedure call,
* an operand position of a procedure call,
* the test position of a conditional,
* the ``right-hand side'' of an assignment,
* any but the last expression in the body of a lambda expression, and
* the application of the first argument to CALL-WITH-VALUES.
The first four contexts are normally thought of as accepting exactly one
value; the effect of passing extra values to such continuations is
unspecified.
The fifth context above ignores any values it receives and so accepts any
number of values, including zero.
In the final context above, the given values are supplied as arguments to
the second argument in the call to CALL-WITH-VALUES. Correspondingly, the
arity of the continuation is precisely that of the second argument.
==========
The point of the above is to clarify what we intend. In particular, I
wanted to make it clear exactly what was unspecified and to completely
specify the arity of the ``for-effect'' context. I also believe that this
description may satisfy Morry's concern about the arity of continuations
created by CALL-WITH-VALUES.
-- Next, I don't think I agree with John that Alan's cheapo implementation
of multiple values is correct. In particular, I think that the
implementation of VALUES given ought to work; that is, I think that I
should be able to make multiple-argument calls on continuations when I know
their arity. In Alan's implementation, all continuations take exactly one
argument.
As an example of why I think this is important, consider using CALL/CC for
an escape function from a loop. When I want to escape returning multiple
values, I have to jump through hoops in Alan's implementation, whereas I
can do the obvious thing in a correct one.
-- Finally, as a side note, perhaps we could take this opportunity to
further unspecify the returned values of SET! expressions and the various
side-effecting primitives. As it is, we say that they return a single
unspecified value. Could we go a bit further and say that they return an
unspecified number of unspecified values? I'd like to be able to implement
them as returning zero values in Scheme Xerox.
Pavel
∂30-Aug-89 0522 ramsdell@linus.mitre.org multiple values and call/cc.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 30 Aug 89 05:22:15 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA01428; Wed, 30 Aug 89 08:00:26 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA03252; Wed, 30 Aug 89 08:01:18 EDT
Posted-Date: Wed, 30 Aug 89 07:54:33 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA02579; Wed, 30 Aug 89 07:54:35 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8908301154.AA02579@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Cc: ramsdell@linus.mitre.org, guttman@linus.mitre.org
Subject: multiple values and call/cc.
In-Reply-To: Your message of Tue, 29 Aug 89 12:51:36 -0700.
<8908291951.AA00670@sesame.Stanford.EDU>
Date: Wed, 30 Aug 89 07:54:33 EDT
>> From: mkatz@sesame.stanford.edu (Morris Katz)
...
>> (with-values
>> (call-with-current-continuation
>> (lambda (c)
>> (set! cont c)
>> (values 1 2)))
>> cons)
I do not understand your example. It seems to me the generator does
not evaluate to a procedure applicable to zero arguments. Independent
of the example, I think I get your point. What the proposal should
say is that values could be defined as:
(define (values . args)
(call-with-current-continuation
(lambda (cont) (apply cont args))))
and with-values creates a continuation with arity exactly matching the
arity of the receiver. The arity of ordinary continuations is to be
left unspecified. So let me try one more time.
--------------------------------
(values obj ...) essential procedure
Applies the current continuation to 0 or more values. It is used to
return multiple values (see with-values). Values could be defined as:
(define (values . args)
(call-with-current-continuation
(lambda (cont) (apply cont args))))
(with-values generator receiver) essential procedure
Returns the result of applying the procedure 'receiver' to the values
produced by calling procedure 'generator' with no arguments. It is an
error if 'receiver' cannot be applied to the number of values returned
by 'generator' or if 'generator' cannot be called with zero arguments.
Within procedure 'generator', the initial escape procedure returned by
call-with-current-continuation is 'receiver'.
(with-values
(lambda ()
(values 1 2))
cons) => (1 . 2)
(with-values
(lambda ()
(call-with-current-continuation
(lambda (k)
(k 1 2))
cons) => (1 . 2)
-------------------------------
Notice that the discussion of the arity of ordinary continuations must
be moved to the section describing call-with-current-continuation. I
have yet to draft any text, but I have not forgotten the problem.
John
∂30-Aug-89 0528 ramsdell@linus.mitre.org Re: Multiple values
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 30 Aug 89 05:27:45 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA01456; Wed, 30 Aug 89 08:09:12 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA03295; Wed, 30 Aug 89 08:10:06 EDT
Posted-Date: Wed, 30 Aug 89 08:03:21 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA02590; Wed, 30 Aug 89 08:03:23 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8908301203.AA02590@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Subject: Re: Multiple values
In-Reply-To: Your message of Tue, 29 Aug 89 19:10:26 -0700.
<890829-190856-4440@Xerox>
Date: Wed, 30 Aug 89 08:03:21 EDT
>> From: Pavel.pa@xerox.com
...
>> -- At BASH, we decided that what has been called WITH-VALUES would be
>> better named CALL-WITH-VALUES, to be consistent with CALL-WITH-INPUT-FILE.
>> I still agree with this, but wouldn't hold up progress if others were
>> strongly opposed to this name.
I am quite willing to entertain suggestions for alternative names, but
how about waiting until after we get agreement on the basic proposal?
John
PS. Sorry about the unbalanced parens in my last note. The example
should be:
(with-values
(lambda ()
(call-with-current-continuation
(lambda (k)
(k 1 2))))
cons) => (1 . 2)
∂30-Aug-89 1205 katz@polya.stanford.edu Multiple values
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 30 Aug 89 12:05:34 PDT
Received: from Polya.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA05125; Wed, 30 Aug 89 14:39:29 EDT
Received: by Polya.Stanford.EDU (5.61/25-eef) id AA19695; Wed, 30 Aug 89 11:38:49 -0700
Date: Wed, 30 Aug 89 11:38:49 -0700
From: Morris J. Katz <katz@polya.stanford.edu>
Message-Id: <8908301838.AA19695@Polya.Stanford.EDU>
To: Pavel.pa@xerox.com
Cc: RRRS-Authors@life.ai.mit.edu, Pavel.pa@xerox.com
In-Reply-To: Pavel.pa@xerox.com's message of Tue, 29 Aug 89 19:10:26 PDT <890829-190856-4440@Xerox>
Subject: Multiple values
Date: Tue, 29 Aug 89 19:10:26 PDT
From: Pavel.pa@xerox.com
-- Finally, as a side note, perhaps we could take this opportunity to
further unspecify the returned values of SET! expressions and the various
side-effecting primitives. As it is, we say that they return a single
unspecified value. Could we go a bit further and say that they return an
unspecified number of unspecified values? I'd like to be able to implement
them as returning zero values in Scheme Xerox.
I agree. This is one of the cases that Mike and I had in mind when we
stated in our original proposal that we would need to discuss the
arity of all existing Scheme procedures.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂30-Aug-89 1310 ramsdell@linus.mitre.org Revised multiple values and call/cc.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 30 Aug 89 13:09:59 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA05916; Wed, 30 Aug 89 15:45:04 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA13398; Wed, 30 Aug 89 15:45:53 EDT
Posted-Date: Wed, 30 Aug 89 15:39:08 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA02909; Wed, 30 Aug 89 15:39:10 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8908301939.AA02909@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Cc: ramsdell@linus.mitre.org
Subject: Revised multiple values and call/cc.
In-Reply-To: Your message of Wed, 30 Aug 89 07:54:33 -0400.
<8908301154.AA02579@huxley.mitre.org>
Date: Wed, 30 Aug 89 15:39:08 EDT
Let me revise the proposal by substituting
Within procedure 'generator', the initial escape procedure returned
by call-with-current-continuation is like 'receiver' except that
this escape procedure's continuation is the one that was in effect
when the evaluation of the with-values expression began (see
call-with-current-continuation).
for
Within procedure 'generator', the initial escape procedure returned
by call-with-current-continuation is 'receiver'.
--------------------------------
(values obj ...) essential procedure
Applies the current continuation to 0 or more values. It is used to
return multiple values (see with-values). Values could be defined as:
(define (values . args)
(call-with-current-continuation
(lambda (cont) (apply cont args))))
(with-values generator receiver) essential procedure
Returns the result of applying the procedure 'receiver' to the values
produced by calling procedure 'generator' with no arguments. It is an
error if 'receiver' cannot be applied to the number of values returned
by 'generator' or if 'generator' cannot be called with zero arguments.
Within procedure 'generator', the initial escape procedure returned by
call-with-current-continuation is like 'receiver' except that this
escape procedure's continuation is the one that was in effect when
the evaluation of the with-values expression began (see
call-with-current-continuation).
(with-values
(lambda ()
(values 1 2))
cons) => (1 . 2)
(with-values
(lambda ()
(call-with-current-continuation
(lambda (k)
(k 1 2))))
cons) => (1 . 2)
-------------------------------
Notice that the discussion of the arity of ordinary continuations must
be moved to the section describing call-with-current-continuation. I
have yet to draft any text, but I have not forgotten the problem.
John
∂30-Aug-89 1522 dyb@iuvax.cs.indiana.edu Re: Multiple values for R4RS
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 30 Aug 89 15:21:59 PDT
Received: from iuvax.cs.indiana.edu by life.ai.mit.edu (4.1/AI-4.10) id AA07362; Wed, 30 Aug 89 17:55:49 EDT
Message-Id: <8908302155.AA07362@life.ai.mit.edu>
Received: by iuvax.cs.indiana.edu
Date: Wed, 30 Aug 89 16:56:19 -0500
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
To: rrrs-authors@life.ai.mit.edu
Subject: Re: Multiple values for R4RS
> Date: Fri, 25 Aug 89 21:18:22 PDT
> From: will@cs.uoregon.edu
> Subject: Multiple values for R4RS
>
> The reason I don't like a semantics in which (VALUES E) is not required
> to be the same as E doesn't have anything to do with whether I can
> implement the semantics I like (I can, regardless). It has a little bit
> to do with whether I can write certain portable programs (see example
> below), but not much. It mainly has to do with the complexity of Scheme
> considered as a programming language independent of its implementations.
>
> The only way that I can see to understand or explain a semantics in
> which (VALUES E) is not required to be the same as E is to postulate
> an entirely new kind of object whose sole purpose is to communicate
> between VALUES and receivers of multiple values. I then have to say
> that the effect is undefined (or an error) if this new kind of object
> ever gets passed to an ordinary continuation, procedure, or special
> form (e.g. IF). That's a considerable amount of intellectual overhead
> if the only reason for it is to allow some particular implementation
> "to signal an error whenever someone attempts to return (VALUES ...)
> to a context where multiple values aren't expected, or something other
> than (VALUES ...) to a context expecting multiple values".
I don't see it. If you want to build "values" and "with-values" into
the semantics, where "(values e)" is distinct from "e", you will have
to use a tagged sequence instead of a sequence, add a few lines total
for "values" and "with-values", make a slight modification to "send",
and make another slight modification to "single". Am I missing
something?
> Here's an example of a potentially useful procedure that would be
> less useful if (VALUES E) is not required to be the same as E:
>
> ; Given two procedures F and G, COMPOSE returns a procedure that
> ; acts as the composition of F and G. The arguments to F consist
> ; of all the values returned by G.
This is a good example, one I hadn't considered.
> I have given two reasons in this message, both of which are independent
> of the truncation feature. I'm curious to know what you think of them,
> and even more curious to know why signalling that error is so important
> to you.
My reasoning is based on the assumptions that (a) it is likely that a
program that doesn't work if "(values e)" is distinct from "e" was
probably written that way by mistake, and (b) any program written with
the assumption that "(values e)" was equivalent to "e" could be easily
rewritten to one that does not assume that "(values e)" is equivalent
to "e". Clearly, assumption (b) was incorrect.
I now see that there is some value in requiring "(values e)" to be the
same as "e", even in the absense of the infamous "truncation" feature.
There is also some value in requiring (or allowing) "(values e)" to be
distinct from "e". I see the latter as simpler, not more eomplex, both
in terms of the semantics and in terms of the implementation. However,
as I said at Snowbird, I am willing to defer to the judgement of the
majority on this issue.
Kent
∂30-Aug-89 1802 @mc.lcs.mit.edu:hieb@iuvax.cs.indiana.edu mv continuations
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 30 Aug 89 18:01:56 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA00352; Wed, 30 Aug 89 20:54:31 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa17977;
30 Aug 89 14:51 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 30 Aug 89 14:39:34 EDT
Received: from IUVAX.CS.INDIANA.EDU by mintaka.lcs.mit.edu id aa17566;
30 Aug 89 14:24 EDT
Received: by iuvax.cs.indiana.edu
Date: Wed, 30 Aug 89 13:13:48 -0500
From: Robert Hieb <hieb@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: mv continuations
Message-Id: <8908301424.aa17566@mintaka.lcs.mit.edu>
From ramsdell@linus.mitre.org Wed Aug 30 07:09:54 1989
...I think I get your point. What the proposal should
say is that values could be defined as:
(define (values . args)
(call-with-current-continuation
(lambda (cont) (apply cont args))))
Fine.
and with-values creates a continuation with arity exactly matching the
arity of the receiver...
Not so fine. I think we should avoid saying anything about the "arity" of
such continuations. The proposal goes on to say:
Returns the result of applying the procedure 'receiver' to the values
produced by calling procedure 'generator' with no arguments. It is an
error if 'receiver' cannot be applied to the number of values returned
by 'generator' or if 'generator' cannot be called with zero arguments.
Here it seems that it is the procedure call that is source of any arity
errors, not the continuation itself. It is quite reasonable for the
continuation itself to be of indefinite arity; in fact, that is way
the current R*S semantics has it, and the way an implementation
might handle it.
A similar confusion is also apparent in the following:
Within procedure 'generator', the initial escape procedure returned by
call-with-current-continuation is 'receiver'.
"receiver" just evaluates to a value; it may or may not be an "escape
procedure." The continuation created by "with-values" for the invocation
of "generator" is not the same as the value returned by "receiver."
The continuation is rather the application of the value returned by
"receiver" to the values returned by "generator" plus the continuation
of the call to "with-values."
∂30-Aug-89 1833 @mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com Re: Programmer-defined data types, version 2
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 30 Aug 89 18:33:32 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA00691; Wed, 30 Aug 89 21:22:44 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa18099;
30 Aug 89 14:55 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 30 Aug 89 14:45:40 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa17724;
30 Aug 89 14:38 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA05117; Wed, 30 Aug 89 14:37:34 EDT
Received: from Xerox.COM (xerox.com) by zurich.ai.mit.edu; Wed, 30 Aug 89 14:34:11 edt
Received: from Semillon.ms by ArpaGateway.ms ; 30 AUG 89 10:28:43 PDT
Date: Wed, 30 Aug 89 10:20:29 PDT
From: Pavel.pa@xerox.com
Subject: Re: Programmer-defined data types, version 2
In-Reply-To: <8908301634.AA00973@hobbes.ads.com>
To: RRRS-Authors@zurich.ai.mit.edu
Message-Id: <890830-102843-5610@Xerox>
Concerning Andy's two points.
External representation: This is not as easy to solve as you might
initially think. Note that the ``type-name'' has no semantic import
whatsoever; in particular, it is not guaranteed to be different from all
other type-name's in the system. Record-type descriptors are
(purposefully) entirely anonymous values; thus, there is no way to map a
type-name back into a descriptor and so no way for the reader to deal with
a syntax of the form #{ "TYPENAME" ... }.
Adding fields to records or record-types dynamically: This seems to me an
interesting facility that could be built on top of the primitives
described. I'm very concerned that we not hair up this very simple
functionality with extras that can be built on top of what's already here;
such extras should be added to the library and experimented with by the
community. The records facility is not intended to be an object-oriented
facility; it captures exactly one simple notion: tuples with a fixed set of
named components.
Pavel
∂30-Aug-89 2012 @mc.lcs.mit.edu,@life.ai.mit.edu:andy@ads.com Re: Programmer-defined data types, version 2
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 30 Aug 89 20:11:53 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA02068; Wed, 30 Aug 89 22:58:50 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa18107;
30 Aug 89 14:55 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 30 Aug 89 14:45:52 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa17749;
30 Aug 89 14:41 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA05133; Wed, 30 Aug 89 14:40:59 EDT
Received: from hobbes.ads.com ([128.229.1.19]) by zurich.ai.mit.edu; Wed, 30 Aug 89 14:37:44 edt
Received: by hobbes.ads.com (5.59/1.11)
id AA00973; Wed, 30 Aug 89 09:34:48 PDT
Date: Wed, 30 Aug 89 09:34:48 PDT
From: Andy Cromarty <andy@ads.com>
Message-Id: <8908301634.AA00973@hobbes.ads.com>
To: RRRS-Authors@zurich.ai.mit.edu
Subject: Re: Programmer-defined data types, version 2
Cc: Pavel.pa@xerox.com, andy%hobbes@ads.com
I like Pavel's record operators proposal.
Reading it, I had two thoughts about additional capabilities that
we may wish to consider. (I feel no religious fervor regarding
this two proposals; I'm simply suggesting them for joint consideration.)
1. It would be useful to have an "external representation" for records
analogous to those available for lists and vectors:
lists: `( ... )
vectors: '#( ...)
strings: " ... "
records: ???
This seems especially valuable since it takes a lot of legwork to
create a single record instance compared to the cost of typing,
say, '(a b c), or for that matter (list 'a 'b 'c). An external
representation could be helpful where the programmer wishes to
initialize variables within a lexical closure and as a means of
portably transferring record instances between different Scheme
images or implementations without having to generate Scheme source
code on the fly to reproduce those instances. (I assume Pavel's
note about not proposing "any general macro for definition of
record types" was not intended to refer to external representations
of record instances.)
I realize that this risks reopening the debate about reserving
everyone's favorite characters, but as a strawman, we might use
something like '#{ "TYPENAME" ... }, with appropriately fleshing out
of details.
2. As I read Pavel's proposal, records are polymorphic but of fixed
extent. But there are cases where it is useful to be able to extend
set of fields of a record dynamically. For example, we might
wish to use records to implement an "object-oriented" sublanguage
and use a separate field for each method; fixed-extent records
would not allow extension of the set of methods once a type had
been declared. (Of course, there are ways around this, e.g. naming
one field "methods" and holding some dynamic-extent data structure
like a list in that field, but this seems a little like the
observation that "you can implement LISP lists using FORTRAN
arrays"---true but not very interesting.) Fixed extent does feel
like a little bit of a limitation of the potential of records as
a data structure. Perhaps we should consider a (non-essential?)
procedure that extends the set of fields of a record type
(non-essential because it could complicate things and slow performance
for some implementation techniques).
asc
∂30-Aug-89 2042 @mc.lcs.mit.edu,@life.ai.mit.edu:katz@polya.stanford.edu Programmer-defined data types, version 2
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 30 Aug 89 20:42:34 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA02365; Wed, 30 Aug 89 23:30:16 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa18439;
30 Aug 89 15:08 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 30 Aug 89 15:08:28 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa18283;
30 Aug 89 15:03 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA05518; Wed, 30 Aug 89 15:02:56 EDT
Received: from Polya.Stanford.EDU (polya.stanford.edu) by zurich.ai.mit.edu; Wed, 30 Aug 89 14:59:43 edt
Received: by Polya.Stanford.EDU (5.61/25-eef) id AA20609; Wed, 30 Aug 89 12:02:13 -0700
Date: Wed, 30 Aug 89 12:02:13 -0700
From: "Morris J. Katz" <katz@polya.stanford.edu>
Message-Id: <8908301902.AA20609@Polya.Stanford.EDU>
To: rRRS-Authors@zurich.ai.mit.edu
Subject: Programmer-defined data types, version 2
In-Reply-To: Pavel.pa@xerox.com's message of Tue, 29 Aug 89 18:29:19 PDT <890829-184715-4408@Xerox>
For aesthetic reasons I would prefer to see
(MAKE-RECORD-TYPE type-name . field-names)
rather than
(MAKE-RECORD-TYPE type-name field-names)
as the for for MAKE-RECORD-TYPE.
To me
(make-record-type car 'num-doors 'engine-size)
is a lot more elegant than
(make-record-type car '(num-doors engine-size)).
How do others feel?
The only problem I see with my proposed modification is that it is not
clear what to do about RECORD-CONSTRUCTOR. If it were redefined as
(RECORD-CONSTRUCTOR rtd . field-names)
then
(record-constructor car)
would almost have to return a constructor for which no values are
going to be specified (for consistency sake). How then would we say
that all the fields are to be specified?
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂31-Aug-89 0231 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #192
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 31 Aug 89 02:30:53 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA00581; Thu, 31 Aug 89 04:23:37 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa25392;
31 Aug 89 1:12 EDT
Date: 31 AUG 89 00:04:41 EDT
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.mc.lcs.edu>
Subject: Scheme Digest #192
To: Scheme%mc.lcs.mit.edu@mintaka.mc.lcs.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.mc.lcs.edu
Message-Id: <8908310112.aa25392@mintaka.lcs.mit.edu>
Scheme Digest #192 31 AUG 89 00:04:41 EDT
Today's Topics:
MultiProcesing Scheme
umb scheme ??
Xscheme is a-commin'!
Xschsrc.arc (Part 1 of 3)
Xschsrc.arc (Part 3 of 3)
Xschsrc.arc (Part 2 of 3)
xscheme.arc (Part 1 of 3)
Xscheme.arc (Part 2 of 3)
Xscheme.arc (Part 3 of 3)
----------------------------------------------------------------------
Date: 29 Aug 89 15:03:24 GMT
From: Richard M Emberson <rme@WDL1.FAC.FORD.COM>
Subject: MultiProcesing Scheme
Message-Id: <3950001@wdl1.UUCP>
Do people really use engines to get a multiprocessing capability
in scheme? What are some alternate approaches?
rme@wdl1@fac.ford.com
------------------------------
Date: 30 Aug 89 03:35:37 GMT
From: Ozan Yigit <ukma!mailrus!jarvis.csri.toronto.edu!utgpu!utzoo!censor!geac!yunexus!oz@psuvax1.cs.psu.edu>
Subject: umb scheme ??
Message-Id: <3477@yunexus.UUCP>
Somebody from Univ. of Mass. had posted a message about the
availability of a portable/small scheme interpreter (umb scheme ??).
Whatever happened to it ?? I heard nothing from the author, and
lost the address after mailing to him.
oz
--
The king: If there's no meaning Usenet: oz@nexus.yorku.ca
in it, that saves a world of trouble ......!uunet!utai!yunexus!oz
you know, as we needn't try to find any. Bitnet: oz@[yulibra|yuyetti]
Lewis Carroll (Alice in Wonderland) Phonet: +1 416 736-5257x3976
------------------------------
Date: 30 Aug 89 02:56:44 GMT
From: jdm <usc!henry.jpl.nasa.gov!elroy.jpl.nasa.gov!zardoz!dhw68k!hodge!jdm@bloom-beacon.mit.edu>
Subject: Xscheme is a-commin'!
Message-Id: <21721@hodge.UUCP>
I have had numerous requests for a copy of Xscheme 0.17. I am
therefore posting the entire thing (executable and source) on
this wall rather than comp.binaries.ibm.pc because 1) the majority
of people who want it read comp.lang.scheme, and 2) files
submitted to comp.binaries can take weeks to be posted.
I am not in contact with Dave Betz and I have no idea when the next
version of Xscheme will be out. I only started in scheme several
weeks ago, so contact him via BITNET if you need to.
The files xscheme.arc and xschsrc.arc are uuencoded and seperated
into three postings each.
Have fun and keep your nose clean,
--
"I'm an anthropologist, not a computer systems architect, damit!"
jdm@hodge.cts.com [uunet zardoz crash]!hodge!jdm
James D. Murray, Ethnounixologist TEL: (714) 998-7750 Ext. 129
Hodge Computer Research Corporation FAX: (714) 921-8038
1588 North Batavia Street
Orange, California 92667 USA
------------------------------
Date: 30 Aug 89 03:03:19 GMT
From: jdm <usc!henry.jpl.nasa.gov!elroy.jpl.nasa.gov!zardoz!dhw68k!hodge!jdm@bloom-beacon.mit.edu>
Subject: Xschsrc.arc (Part 1 of 3)
Message-Id: <21725@hodge.UUCP>
begin 666 xschsrc.arc
M&@A-04M%1DE,10 1="P$ ",2<SRB+8T! ,3X0HB=$#SYPQ:,JT*>/B
MC1@U( R26=BFX<.(<\S0"2/&(D2#:=J$.</0X<<Y:=YXQ&AR)9<&"@S"D9/&
M#9V5!N64"4,&YYPY>2J:Q&BFCIL8/HNZD>%3)!TT+F&V↑4FGCADS'F'"#*A$
M1D&4;M+<'&IPS!NA%T':S*H YA C3((<F=*C11LV(%J8R?LD[Y&\=UK 21,&
M< LR9?:V"!RFSIR\2<;HX%)5CI@W8[C4',.F#F*M"ER,\:@#9@(Z8\;D54T"
MQ=NX<U. (,$#=-F$"UV4P5-&1X+67&/(!BY01@K3=-C47 ,"R&V%#-FX60.:
M↑, 4OI_G1@/3NO'L!W$S1(-1C%G$+K@KT :"$U34U151D8N0P !%UD$
M+Q'CE?6?Q2$ PO5(!H,V<.G3IFS+@8 Z+%P#DMR+R9 V(.G#)CTIA)PU#.
MFSITTK@I0U'%BP8*4(X0.89-'3)E0/"0.,<%&A\J6;J$"4($GCECT)1I4\:F
M")0J86X<"8*)D"E)M!0!(0,&#*0* H(H@X=.&3ENPK !82>,G#1AQ+ A"<(D
M2JY>P3:U$H1)Q2]UW(CYZ(8,"SIRZI39\;;K5S<@C"1A,E4%'3-P""N >QB$
M2#I;Y8!](QFE5C9OQH@E:Q:M6K9N%1@,$Y)A4+,@V(A!N,4I5*E=)*]N;=D-
M9C9P)M9↑&K5(;I2[.?;↑+1(F'MUT6"N_''L,7SK0I3.D#GQBFI!OW&3G#=K-
M&1!RYI0I0P9$#Q QF'3.*M"[F↑\->W]'RR:-GIBIV?<="F*$X<9(<J2 $@@@
MO"9'6P4>↑)5D>RP("0%PG.6;&2B(4,(<7+@A @L1(IB"9"!<V-T<↑X7G'@@P
MH*AB<UR]&*.%!+!A75Z8O7>C GU@I=5$2Z4Q!QKYM52&@2#4 0<(8I1AQAMR
MQ%3E06")=!X=;X! AU @O'&1'-*95U$>!@W5UDD*$"F2D6B@H* "%0(I9'WJ
M:49E?AE2Q↑17'CU(5$%AG $@FQ,!2B4*!)TQ)X,.MM4HA3CVN6&'BLJA P@?
MACABHR>B%&1*](4Y!YE]Y7=E'7*%@9Z!$K4!@AMUM!'E@U'2<<=ZB,$ JRS
MMA##FBA1-Q&J9*#@QJ/+S4JI BGF&-YY:\0P7[1:M1'&&C'-P6I,NX(@D1LG
M8&8H9@;5,<8:OV+VGT?$0GNA1B"@D-YZ[?7@(Q,IH*<>>R_&=↑V%6HEU!I7?
MH2%K=-PB9H9'LA(AAPL@$/&&&&)0I,1'8(G% @A.O&''4+?"EP,.-7P,1Z$Q
MY3!L:M%6↑↑*] +\ GPPW0#+ #/+A2"\*]OZ;+WPVX ###78)%#2↑↑<DL4 PX
MZ\QSOPXY314.,]C KTPP\HM2 C2WM\)[,L1 PPTT8&W#V3V3BJU J[;Z:E]O
MR$JKK5]!68:NO,+X:ZIN"!MOM'$C!O1E*2P-< GUEN?HLJ':2>J0<X0A9AF(
M.70Y8DR& 50::8"PT5KQ*L986Q-9?I$;RH9!% MMO $3LY&J$-;K*L0.T[.$
M[\VJX5.NWOKKNI>10N2C>H;G7JOGM_FO4(ID5AZBIT%Z:J8W-A'SF ]?!NRR
M&[]@@VC 9KOKW↑<>/N\71BI&\5O$ ,-Q\A)@D!QCP)$'@<6#/_L.%0&,:.C
MO_"Q0 1B$$'D>H<EX&W.>R0JWO$DD[Q23:0EB4H2:-0#O=$=JEB↑,14&U8,"
MR# K>VV!#/L(4+AZF6&$92@A'"8HJCN9RBML&(M#SN4E,(V!554*H0=!$!P6
M@0<QJ7'<#<N00QF><#&-42%*ZL3 W[D0AVQP(O)L.)%_L<LAZL',EV+R0\U@
M#C-#+&*+D,@F8Q5D/6N0(0O>D) PLN .0G'#&,0'K<1 ,861B<VTPE3'O0&0
M.GC$W!Y7V,(2>E&.=#2#'1.I1↑-M<7)X8AD=&++#O4'/06$80UQ$![&__>IS
MH1MB:MRHR3$X<7PH5($4Z82C1I[+E2:\I/),%08X@(231 3))\M')E'FC4NF
M]%Q&4FF]#RJ E;[<) J"P@(3CH\Z00%@+&=)Q0LU,IJNI&8N*<C%.8CAEOGA
MH:M :<P'/:QNT!.#].1 /56V,83;N↑4K↑[C-R$RQEKZ3"PKT.<X:8M)48@ G
MGX2Y3F*&<I3(=)4\PT+/ZEWOGIC9'CBGB89JSO":(<RF'T\G2W_2LG[?_"5'
M/4I#R>UR(G1 9R<QTU"S/#1O[UP8F.+2!NF-997X-(@↑Y]1- F 3#0,C@%:"
M@A%V3>E!$D6(&;X",':.$F;S,D/C=N2;%K1@3F +J.%D0YO↑](4K*UA!%R*'
M(ZVH$S$BB69L1.+,:#UUJ]>Q$0 !"-8YW.$[0:E78-↑#AZ'VJTX)$ T'3\ %
M.9Q !U]+ %G-L 4=72>M77@18\DEF00D \;9:QC3P0"T*ITLR<@[8K6J-?(
M_NPQ'U6 9↑VZ)Q28U3EZG>M9\< UR_((@&F]+5? JK/4;72RE:41'KKP%Q-V
M5K+*S:UON]J"YS82N<+% V8CEUC/Q82Q,)#?8[↑FV.]R(08WN,%X99N GTV7
M#H>-;+3>Z]7G1@N/S6R<&H\( A_$IHB5Y2H=U@H"Q.K,M-($KWA)BV!7G@ $
MJ05@@U&@8!A$↑&LZ6↑T1ZRO?"XW*LQ].@!BJM*W.EA?"7(#!#&2P7L_BP0PN
M.9*<K"O6>A7A"4;@KE+"4 <VT &R[/W98-_#6#H\F ]\$"R2?. C/%0%!"8P
M ?FX!@,\W"#'\67O?&=#V?=F]CW9['". .SE%VDX#>&Q;U:5[!XB<\'(Q!V
M1 J,X0%$:\(/OK!L==8'$."7="@([G[1C!@IWX"["8@6$SEHX %,."BJ'71X
MTJIF H1XO@*F=&1#O.B8(#;1%WIQC..$Z&CY%;!(XFB69]L↑[Z+8*C-X[&=]
M+*:UC"R+)TK 4L,#F#>PH04,20VK"7!B\!Y-UGC0T5H,Y*09ZUH@UO&-1WY]
M'F&#FMBN!F]5D&U9WXA$,,[>M;1]W8(G63M:Q4[QBF7=R!OG> ?/;A"OI]T"
M/<1KV#ON\8\]VTA(5SK$'QY5!2E'!X4Z1*XU+29$NS1&+WVEIV'Y*:(,LE%(
M@Q0S83[IV\C75-'M*=J]'HM5OU(2-D7K@D)9UXRQLO&/%%R8#1_Y@[!J5*UR
MM,TH)M>J\=S8")<VM"'2LV0EC1@?R<C2..HTG67[:#1P]\R37H&,!E#!% U@
M2""1:\P=VDXO,7RGJ +*6>" QOQB=0"OM:9LC:M2:L)6EQ:< XSK<*3\S+WN
M#>>I3WLC5RY/=>83OSNI_UF_[)I9P&8F>FM=&G>FKBM)*7?JQ↑?M:_+9M)T4
M(0.KM+05/& $)(2.%\J;*B?"1↑NH1Q<RD@CK↑#@>[VNGWF2J(;WT[BXVQ3!@
ML0[B#7)ZB↑'>=Q;\RF5[9]F0.(XB$((4BA"$)8QH#GC1"U_(P-UHC7A):S!Q
MMG$?Z]V+.↑3 !GZHA5_]4-,:#K9FXO"O??T2DW?[N:>!K+]/;\P(↑\XBF=+Z
MK7]\[=\↑]]W'>Y3W:R7W-?>%!OF% GC0>G(" B'@9KD7 ZD569W%?]C760)G
M0WB0?UT"1FCP!G?0&T↑E+?SE(KU';O;')LG!$!OH!OI'5,J3=(8A%]3A@E7R
M/6<P!J*10W-P=)0A%TK$)='!!D?G/K1A-/1C:I;R& 2"$ <4(EN0&#>X*27@
M%R!P!$/0(&+!!G- A59(!6\PA%3(!NW1!2-B@!=B@↑O! CFX@USX%V$H%@MT
M(8 23??3A&80.:DQ< (A:G2') XA>#T4$W$E3&85$WZ7-\"R&G) 4[-2!B%X
MB/&R@J5%?J9W(40R:L-W<A1W6D$'=UI16'L#3.ID>0J'4Z64=P↑W=W_U)2ZW
M%4'1):E!B=0ABM($@RA58P1"$RAP RP [_8+U)694;P;@:U2PVV4(XH<UXW
MB XG!Q W&K,8';S1=,R">I=( &+ BS; M0$ Z#8AZT'>1UW5PEW4X"''-0X
M'2&T@)%7>AKG3;JXC1.! MU(C$80C% &(WA0C.%86B(A!GG@%:JR).TA40,9
M$SEE2H6(&<'1B/'"!'1A%RTHD%X!CT5%'0])!V[ &3@BD75!&D2((V4Q%H3%
M!F<0!AN!!W<S8T1$)1S9)>↑! HAS+BO9DB4YAP20;&S@.=$A!V>PB?+80()E
M!S=9*T"C&%A !5D !460 G&% AO9D2F@,↑1T4'C@<A89$PYQ!V=!D A)D!&%
M&"XG5QL9D1-96EJ9D!CI,R$TE6] (@EY="!I%R5Y="7Y(LF6DD?9!BX)ER]"
MD[Z1 C:9!BR)E#F)EZ-QDGQIF"U)6EL9F#6Y-WV) HF)(SSIDV81E#I9EE()
MDQTIEUZADXWD!(OQCRU(!SA@ _DA$G;P!MP"/7. )EXA*Y<!*$Z2@BA1EP#I
M&ZO9EO63%Z&W?$<P!;U1)6<P!W,$$LC9@SAR/↑J"&5- G,9Y*F60G'29EJZY
MG'1@!RQPEVZ)&9?1D4GE5I[4<+>I&;DY*[52,L#2</UA$(2$'M=I)*-4DH)1
M@/63EXRIDHZ)E*0UGC)9+Y/Y&/_IEY=9/ZZIER@9!B,C2HO2F2!A!PR:D@_*
M)7(@E#N90YH)E,/75M 6><YXH7NR%N;Q)?IY>C9W+BSR'X)I!_WR@""0 X\"
M"0B0;)G2(2Q!)54B2F2!$1@:&YAS!E\R(JZIDS_#HOX10RX'HP[X'C3Z-3BJ
M)QDJ CMJ1CY*H@]BHD2*!B/2I&Q5/Y_Q!F'0'DL26,AIGZ@(3↑CI!G*EI8-S
M(?P) N?"1$-Q1B\:C*GG!LWI GC@ F' 6S.YDG!@F7(( C] H(-9F(>)H(>Z
M*>"HF"9)IWMCIT3A&WD: TC*I]=9$W\J!H+J0H99J#F)J(H*7XR*DX\*(SHY
MIW6Z%I=*0-LI YO:IW\Z!J%:0J-JJ&S0+XDJF*A*F0?*J_T"J:VZF)2*0W>*
MJ=LY [7:J7[J F20JX1*K*8*K(0IK(UJK<8JJ2_RJLLJJV[@G33PK,D9K2P2
MF-5:JK]:H)59JMU*DL@*KK&:IS5@KIXJK:$SJ+O*KJ>:K0:ZK?#*JM[Z'O2*
MI]MI SIIG>?*%OP*6M;:KHNJK:K:JR 0K_LYKY4*JP@[KBQP:$?'L#5!!A3Q
ML*1ZJ!(;K %;L<5*L/(ZJ0?+K!Z+ _@:K6, 8X6BKOV*LO↑:JHBYJI'*<@0C
M$'/6<+.9)K;I&[A)=G%J5+YI W@ K*%I B+1G"Q@ BYGM28@LF&Z<09!)3'1
M<%7B+3Y&$2+AC&4I3'!*<V%DJ7C:I+_HC48YK"B@E$SIE"F0M=#ZIX':4J:V
ML>&* G ; W);F76;!$O9E$↑IM↑?ZJ7C@MQ?2MAR+J7 K X5+MW:KN'G+G'N[
M$(↑[L(!;KW [ Y>[K8>;N'C+N/DZK9!K/Z'[MA/* C10NBUYNG>[N)S;N"[
M(JTKN8$+MRDS!G-KNIF;NKF[NFG0NZ]+N;';C<)KN,7[E"+K B2AO,HJNK'K
MB\↑+N8A[NRDPO21KO6[+O-W) CA NTAINYJKNC:+LXZBDR!*GT0IMB2A;W,E
MGS372&!ZE;MT+B/1%>ETGF#ROV77J*0$3ZX2G[JI&NNX'2'DOW AE0K,++RI
M NAGGRO$F↑"IH#87;1:! A8\P5F6(@@PIZ*1H2%LG]R5PO()9F2 PA=L$-SU
M,R&PKG((5L67HR+ %1<A2IS')+=I*'(P(@E*PHV$K3[KJ+VJDZ-210(5M(P7
MBD=;F_G!%9\'EF>"M/+6!MJ2*JG!FS]!FT,!G.A&3&TQ!FU !CT@ D/P!$W0
M!$'@!$0@ JEG<[%#8D Y!W("5F@\-!QE/@![/UJB@ TJR.:QQT>7F8S(F4?7
M2%,\QGW<+_KB-XD*&()QL0TRO+4;O2D *%2)FN?"+=0S4] CR@>L4S$ARGMA
M%NWQQ6EIBZ),QN;7DXNLH?VFR>G+R;;H2E4Y /P;=[-I*[Y&$0YQ1GDS$171
MPQJA',&\%UPH>@61!\+,A< Y*AH &@A53DE84U151BY# 1=6 < # 24*S8
M#@ . ,+U2 J.,F#9XY=.J8,>-B#(@6 POB 3$'3IDQ:<RD<2CG31TZ:=R4
MF0-"Q8L&"E"."#F&31TR94"(.#@&39DV95R@$8%2)4R-(D$P$3(EB98B(&3
M@-%304 09?#0*2/'31@V(.R$D9,FC!@V(TN>5!!U:E6A5H(PH?B%H!B/;LBP
MH".G3ID=*,M2=0/"2!(F2%70,0,'+UFI>T&$I -53M4WAE$↑9?-FS-6L6[M↑
M#6L2)<(P(!W6W J"C1B%6X86/=K%\.?0BMTP9@/GS9S41(T6:>V9#NB-L6>'
MA(G'M6_8BTN/@4O'↑&↑'E-V< 2%G3IDR9$#T !ĆG FV'3,,8XGB05]/H
MB=E9@?B"=%"(">-&I)P4*$& &"VGY/SZ5!FV1WZ0$ '5[*9@8(()<S!A1LB
ML/"??2D8!D*!; P7E78@P& AALL1Q-AV'J+41U-/V094&G.@\=!↑8-$W$!P@
MB%&&&6_($9.."545TG1TO $"'3:!\(9%<OPF'45Y('236"BI.%Z+*."GP( *
MG)@2>$9:YUB.+QZ8G(Q4==0?3G/,$<89[(UE6YDYHM#&'&=8J1]_)<UYAH $
M&HC@8 O"*8<.(#3X8(1Z5F@BBN'-D61<+_)8QUEA4$<?&6↑T 8(;=;1A8W\V
MTG''=7S! ,*EF[80 Y0*)&?;HV2@X(:=P6W*IP(7$A#==&O$\%VN3[41QAHQ
MS3%I3*."@*D;)S#&)F,(U3'&&J<RMEY'K.::$0@H5'===CV0R$0*U%F''8?=
M_5K@4U>=D2-Y:&CJ&[%\F=&1ID3(X0((1+PAAA@D*>%155>Q ((3;]AQTZ?<
MY8!##0;#L69,.:S:7JZ]<NCMN2]P)\,-D PP@W=];HM"M↑:"RYT-.,!PPUH"
MH?SMBQD+%,/'(8],+D0U)X7###:,"P(/'8Z+4@(;9[?"=C+$0,,--/QLP],D
M;PFL0))2:FE<F6[:*<.ACEI&J:="ZH:JV1:8-5\G+Y:"S.>6P.VN*<RJ:):,
M=AG&D6._R#=?,H8Q!T9I@* 16*SZ!5A)MNUMD1NRAH$3"VV\ 1.M>*I@U>0J
M5 [3K;FNS2V.CT<↑N>=EI'"WEI(U↑M;C?L->J1@A;96'X6D@WI[B@=GV↑MBF
MET&YY:GGMQ\:I&DNN?"=$P↑ZVF7TR#;IP&\N/.JJ&\8ZE[:U].:+WEMW*NZZ
MC↑7JX)19AP)AM/)>$F'/$R#Z↑N&7L3X<V2↑Z98I.LH$51,\:4I'&,"D=R89\
M,:G-',B3AC?PI3V[ZM)4_'>_]OTE,/!#"99"%[U)36↑";*C@ZO)F&W-1"R+6
M80R18D) QXR-,8=+H'A XD!6G<↑$]V/!&Q:20A;<P29N&$/Q<-67"[ZO,*5Q
MX'1V:(84[J!6/QR;$.,WOR9>9PTY9&(/HQC$U(UP?XV:&!T< L#HC8\_81B#
M60QWK[*=:G!I*%P,;7C QCUK#!4TGOM4D,$K]6E↑=Q2A]DBH)CA\A(P@,"1C
M*H5&-5)E2$(*'!SEF+LVH>1\85 D'FO" O89+SDU>>(>↑[A!Z$F/6YI$ 2?9
M]\76=4D,=WQ1 !F)O"0YLC_VZMKL:B>'V\VQ/>>#9?3PZ$DBCK(P&OQC!\↑"
M@D"R<I!@?*4FP_21,]8RC6L,TOAH9Y5>(I".C/%=*E>)OT\>,)1%7!P?D>E'
M7)G2@Z@\I"K1T$G\M9)["(EE&1=YO*U@\Y&YE%>1S-*&VF$%F'7,YS"KE$QW
M$@"4:% 7 9Y2DXM0"T?]F9U"S$"5<S5RC1<KD,G8$"+9M* %5D+:,MEF&M1D
M*"Y16<$*NG"W/CUEEGP)B2)+$Q)+.A13(,!2 LSPK#F@H*5F8(%J=,,"A) A
M)'?+51] \,-*<NNH)1T11>@"%L@A577:(5%-'?J4.W!E*HI1H9!6.*1'#8XK
M<("A54/Z4#-P:S#E5,!0P714#4V$1$]\*7&&IASF/%&F@HU*2G/5N%0B=0N)
MQ4,7YL*↑#↑G*KQSR4&%%=%*)/D5T;-5(=1CST4?2=7Z/C:Q,:0I-5]J&#M.$
MR$YIZ<];0E* ,2&H05GUVG&B@580C1]%;3(MPX%I.;+I"%9*6YVT$:![Q,7B
M6*]FI(_LE*W,=:XF:SG/Z:XK/-:M)G:O:5MMLI4N]'EK&N+Z3;J:#*\I;:P\
M.0G?UN+3#"YIT8OP6P?]GI<J!;4*5G1:S=,LQ+1NF@-_J62E4EX6IG_=[ $!
MJS_7#BZZX,,P1O?C0+J\8;GD-0M)R#"I'T$%#Q?Y2 ,?F."*3HNA[=S>4P[2
MI*EH"B)123%:*S6'&C]I.6T0%J3:PX2TK(7&3FH#C!V<N3&T@0P]$$&+1&!9
MDU5.1ULY@U%5=S0GJVR>R4M!4>GR(Q3@@0UG$!R9I5.EJ!;HS&Q0<Y:K9-GY
M]3C)JGPRN<+5(1#\H*UV 0&AQF 'C>"!4TI&@5↑P0(4L0*$(*2B3&]Z0/[Q%
MLX1Y\-2'28)CV3S2-A2Q"$8TXI >:YH-)&D/ID↑]Y89J20, @(04 !H(6%-"
M0T]$12Y( $79($ !T$=.F*7=W" #"]4@, S1\R8-V3*N$ #HL7 .6/0
ME&E3!L3!-G#2L"DC!X28/'0J'DP((J&9-&[2T$GSQLT<$"I>-% 0,,&0-W#R
MR$ES!@T=$"C&I 1(P<.'"P\Y@%!)(R=-&1 -$D3,4P9-B"$E*&C9V:"(&RP
M2N'I\Z64,G,XVBE#QBL4CFW2S)G#T@T(N2#.R GC)F14,V\ZUG$C!RV=G6/\
M@G#3LL5%BG+&I F#M4[:!#%GSAQA$F7%)U"↑")%")4$"&'A@Q$@0T.->-Q%!
MM 1QN$[%S HXESGIYG/HT49,HX8A@[5 ,:]CSS9#.2U,F;D[]P8!6K04X:EG
M&'?--_;@@V[(J*Q+F<U2W+IY↑_[")$GITZEI;&?S)DQ4-BHY4GZ↑6?KZ(U(4
M$1Q\,-2PW1GTB;'?''FT(<8;6-E!F6W\1;>;9]2%=L041;PWG W;I?43@F\H
MB!6##D((@H1L4(B>?QE↑442 PZ7PW9EN/&4'"U1U->*8>P4AA@; =GB;="E
MAV%U17#H86I!A+@5"#GNV&../TDH))$5L>ABDC!6-T405A2!'0Q"A.A416%8
MU-)*;M01QDJSO7CA=-4-$0033)PYQ'9CE ="FV9\1Z===JH78X!45"&%$P02
ML5UA=-0AAUUF\-C&H" 4"MNA%2J)9VA/PF!F:_39!\()+)X PATJ,?13HDN&
MYD02?1(8'*KU1<4J9:["2@=#*6%%ZZA?0%'%%$A@%P,,V\%AF:P2K=HJ"(6=
M(5=('1V[WA!,/,$A?#&LUMH8A<W)ID7TS6$IDII9J&AU1D@11!-FHA9#<>>F
M&Q*GO=U!I8YI:(IEIWM1%&J8H35A11!2'$&N=JVU\<9:V)811QT%LS6H'&?4
MX>-/=+R!<!@*ST'?K&#>N9[#3T LL;[R57QQ13@=NE↑0(8],F\F9HER1RF↑P
MW)_+,3IL;\3D&MB:&!RS$55A<_S$L\@'\Q65Q1B7?'+**R↑,='5!$"$%:.3>
MV!H9/,)!6[54__2&&6↑S"3+6?;WD;8Q[!C%%:?I&67$8:PS];MV%?5P18R!8
MG/C5(↑O=\KRA$5$$$T%D06Z:_9:A+J=P:"H7O H<3?D7$ OH[)↑MA3'&&&B]
MU*:6DW%YEUU\#6RE&S[O3;:3SDK:FHB<TCYDD2@-:E>5!5_Y(VZFUXHZ%4\T
MX>RI LWYQJ:ALT75Y[Z'5D04SNXJD,8_@-"]>('↑&_X73E3!)W8R0-M:G&&E
MCT)@BQ4]U/K?<]_DI#>$)SAA"O0SET# ([GH(4M/UX&/#/BUP"")[71#,!O]
M*+9 MEU0>DZ"H 1K)A 1.29((?@@LD*H0=3(P&DEW(ICV)9"Z,E+>F63%'QH
M8+_LD2$J=+B#R>($&:I0"0_=FTM=&GC#%58A33M4( C<)8;#N(YD0EP,UA!S
MQ"32I25,%-7+Y(<=&E"P<75@PTK@8![:9)&('#%B&9!(M2↑Z1(7KB4(5GE!&
M#I8D#4\A21!-AI*0G($C7:SC$O$8(R9, 8$[)"$(-C*7M↑7N?>/+%6IH $,J
M;6P_7GO?$:@0P4V"J#5Z\1RW+(DHZ&@ &@A84T-(14U%+D, 1=,0< $42
MYI['T_@, ,+U2 P#-G#)HR;<JX& .BQ<""!Q.":!,FC1L0<M[4H6.Q# @5
M+QHH")A@R!LX>>2D.8.&#@@48U* B)$#!PX6(,3D 4$DC)TT9$ T26,P3!DV
M((24H:-'9((@;)!*6=ER#@@I9>:4D6.G#!FG4+:V23-G3IHW%\F".",GC!LZ
M7D&8>2,'1!TW<K+243D&;E W:%N,>=,FH9PQ:<(@K:,U 4B1(D=8',.F#AF/
M(@@:1*@0C0C((P72.0@"3D:V8=KD=.MFZ\>0"D9<-M,Q:1 G3HI(22 "RY3-
M$AU:V6H6+0@8+F+<↑*Q 9,"U;-Z(40S"3AB58<2PR?I:I)HV<+Z(J6,&!)V3
M7[9W9;,#]/.]8<9XI+V]]!N+<.L↑5F D"9,B']%A!AP].%$%$TRTUUQH()2!
M1WYN4&<==MIQMY↑#$(+ A!5!,#$0&V;<Q0(>V[EAQXAL6,>>2!AN==&&'8(P
MQQ=ST$&&12S,6",9&M&1(XTV;B7'CW>)H9$;9"CHG$ MRA$A4AEMU)%5%S[H
M(@C]_??1&V;15P8**2C)($46-60>:61>%"5'K76G0)I@BK2'2"! 0@",'@YV
MF8)U$D"GG<]9E 9'BJ6AAT?[]<FEH'2@(,1MN4D1YI]↑*M#G<WG52)='HWDT
M6QAUL.'2'72M,0<<\96!TQN=RG$'61Z-D5<8<($0!@BMW0$"6HC"UF<:Y:$0
M HEI9'I>7BAD!A%G+MQAJ@@II. 4L6X,>L<<*-0 R0#3+K@I0+Q>*9'C";&
MAJ&TGG61GO,56Z.;?;(+0@\?EO'65LFJD(0325"11(=):%&$"M#R::>\]*)@
MY%UDP '3&Y?)],-:2ZE8QY?LRJ0#"/PRX2VE[[4%1X-R9"0'E;[:">Q+6M'Q
MG</GA:?>4=&",*<""2!<[[URY$O%$U#\9T413!#L;<X0>Y3PPD@ZG#$($Y]1
ML6(7/QPQ"!MW?#2)(5Y$+XGVVC'OARJ.W;&""9!XZMAJT[%&S 83T =HX#:(
M1QEC;,0IFA5=%-U)\*H<K+PAT*OUM-O=G3=<5I?A;9]WB%R'P][.O2")T85!
M!I@V6T[B8&]95+5,>WC.AABSKL'Y'A_&/#,;8.X @NF4E>'6Y*M;OF3K)[UN
M9EYTU.&D>6↑,2_S(ON]'HNMEK!>G C?WN2,<&]78LPA;K#;&&L0?#X+O77#A
M1L&41N?&&2↑C$'-ZS1_%0@R5NR<0UQ4AY5!><-#EDELDF↑PF_6F 71OF< 9I
M60H$1='/ ,↑@H.C9"6PEHPL*%D@D-S"-#/%;T',@Z+_[E2%_<MC?181$E_]M
M)X(]H↑!U"D@G!*+A.A]9H.SP9"LY,%!.( L76># AC#LI%/]*V%"RA(&J06.
M $*B'AVLEZPBH'!CY+.4G9)8O;U,D("/FV+)E,A$$8@OBGW*86E4\A;CK; .
M"2FC<6ZE%52UI5;G:E.B!/>2%8*@<#+Z0I&.A$&;.86*2[2B"$ @B@F((ED
M;-0*LR@W2HG1-/@Q7M?ZHBX0W.$@>3$>">ORAC'DK61QF2,2MUC%Z[T0#G"P
M5UPL D5&(A(_*.#:73XF10(\9PR*00H07XBD$QX1EU'9)"_)<,+8B41W# +F
M"4TV3%\Z1)F:1"$(FNF:_2A3F&XA)KX,Z$ D6FEX+Q,/>7(RAB_<Z%2T,DC<
MQ&@1.[QA#7OSR":GF4U?BG)EL4P1=>@E-3I8[$M@XUF↑=".%)TBA!4BX#1'↑
M(P6C<<N/../29K87NP0\AW\G 6'PJD6''Q8/=;;C7H]V59Y;32<HU-0/;')V
M$(K*X&C4FP,:\ADVF#)FIK)TP]9Z:$.&T$L&:"-1&%#)ACP8$V?F0Q]X%%;.
M<Z**#@9Y'R.163? T+.76\&)&ACCDDPM17O<.X_Q8O:]]B%%E$E-W_I>)U4%
M(7.#/312",T$R3+R;YY#G$,1/9)-6\G5)<J+J_ZNR,(#)C"&!&R@&)W:PQ↑2
M!J]9T:L110G(+@;AKZV,6V6MN$!7DC*0U_LB(Q↑92$G>A9+&N>16XAE$3GI2
M>'D)"F4_V\53IK(U06%E(3TKA[HV*J>TK)M773*=[74/B&1-7LH((-&6JBY,
M%A4(1E&IO[L,RJ,Y2=VN-G+$M"YUK69MZS'E]R$ST(HZ#O&MK>1R7J1 EHA&
M[*N#!F5"\])!,80U("$/JP(9XK"67-ID?C6+AT&A 'YN):]%YF(FQOH0!)<9
MSQG.8)$S@&#!=*$(1XRS'PRCP QM\%$88L"",,B@Q#,H,0WTZT(8J@#$=%!L
M+0\['C-L(08P@$$76* ".,3M5(DT@\+(PP(8EYC$)D:QBADYE[J@8&3TJK'L
M>GQ'>IV "S X@>P,F NT4&)8T!!CU>P@@SN+G)#G9R9:L<_-<NWP"X1*Q!/
MLI5TG4]&>:@10MR$9NI1[K↑_"I: X,!EB49'*↑H;$".Y1)MJR?2H?9IOHV!@
M9@5H !H(6%-#2$5-12Y( $7;L6 !.$G*DJ),;- #"]4@, S9PR:,FW*
MN$ #HL7 @@<3@B!3QDP:-VGHI'GC9@X(%2\:* B88,@;.'GDI#F#A@X(%&-2
M@(B1 P<.%B#$Y %!)(R=-&1 -$EC,$P9-B"$E*&C1V2"(&R02EG9TJ.4,G/*
MR+%3AHQ3*%K;I)DS9Z,;$&-!G)$3Q@V=KB#,O)$#HHX;.5CIJ!SS-J@;CBW&
MO&F34,Z8-&&0ULF: *1(D0%!S,DSYVT;R7#*'+8X9F+%BQG->G2L8 1%BV[*
M@/A"I8H4(4↑&?'E<↑N(8-G4H@N!1F<S&A3Y$CK"-6S</OGDR Q=./+=JWDO5
MM(&S7 %D@4:>2+D21 J1!'22JWYC!D28N'/OA)$3E.+M]6$T<GPIDW1D)K&#
M, $O'@1Y\R"P\<88B<5E%U]FO519?$35%])( @5A1!-4)) '"JY59Y<<K01
M'WITA4$&&7B1A=5+(I2 AP@.7@?"$T8804464!21@!MUM"&&5B#0<9!D:>@Q
M7GEMF3=BB1ZA<!$=+4((@A%)8#%CC0F0$=]YX64&8EQIX $7'&\L"0*..FJ5
MI(!NG-%D9$E,::-%7@8%II@7P5&'2X*YP94<9<TGQQMW7J1:EJJA@.89YM'Q
M!ALHI+"F0$D,X805%L+Y99ANH>6&G7ARM&>?9_T9:&HOQ;?HHR D,6&%%V9(
MQX9S>>@2AUS&"<*<F9*Y(Y\HEL &&2Q↑]&!D1N#G9I57]M@?K68(R&":MV+J
MDJYFOM3L&_&A&B.%%F*X)*P=?LBLLQI!B↑NT.>Z:9 DNQ%"#FL+2%AFM/JK&
M!%5TS)$97$. (-AT:;#!HT--A'&86V_,P1!IPYEQ&@A,3#&$<*<)"H*$W":0
M(ALK4OP9J3#*2*.-"1SJ,6JJ.9'$?@F@8$>80:F0 @PG6]Q$$$,DX0053TR!
MA'!EN.&;&?(*1.↑/5:B,!0A34&89"%: T.↑_< 3,(\-I.%P1"$E'";3061>]
M9;T7Z_%69U,/5K7 =#D4A%AGG(>UUN4%H0451<@61!-)'!%$S:1BS.K&'9=6
M,<@Q'ELR1V=\/;381ZM6L!QK@'!%P&P@UH9':0/,=D,7T[%>&DQ3$6]M= MU
MQ<2&?ZR:X!82+@+@JH6LN,FE!?VX=4Y&+A11?\Y!GDO]UN "#/ZJ;35=<S_<
MA,2T7[QJ[+X6;IKK+R8↑LH6X7X]RJDY,4<01312Q,PINL#!'"BU#,H#M(Z>
MODP↑↑#"3#3+UT,-+*,!?H_SK T'][N<H%WG/9E,@0L\:0C")@<!XR#O<B7R4
MEC#<:3 ,(E!4=L(PW86-=_.:2X]↑1(4ZR$$,;Y!:\CQWM0<U[&&L<0UL9!,]
MV&FL>K-KW??\1[+N21!\XB.?↑:B /O6Q#P7NXZ'\W$ _↑\4 ?R#0'_↑4B((
M#O")!=0A A4X!<=]T$5E$9)_RE,&@S&$4&,$04+:,)>=9.4,"<G4W(2VM?!-
M(0E:*$+T[(A'&]$ !NY+0&2H19?__(4B'LD,70ZIFC?&T24=!!O14$?'\EAA
M"G?,8_0NF4D;Q0"0!!"D0 B91B9803\G2"2/N,(7$3HR:)!TH0<GZ:+36) -
M+DG#=.8BNDP=+C0<&8T+LU;))VF'.]Z)7G:VTQTB>'&2#2LF?H:@G↑A-4S\6
M6I!&QO!,YIBAF(*KX?1N:+U9>K.8/(P>#RVTI&Y2\F%0DM+(E!FEVS'.G=%\
M6)OFJ452[9-*BX.6J1B5 GP24Y↑2LD+T(C6I↑5EHH/,SZ#?UN:J%CG-CP))H
M,8OU!#<ITUC;JQ*@Q" PC<*SHOU4S;8&QRYWG2&'(S#G.[<VA7CRS0G1JVF4
M;FJA%GR2!CBHP0ULD%.;!@$+%OII4&]0 Y-N;0A6@ (5I! ]J$I5"BC PQ&U
MZM3RZ"R(Y=O90L,WOK 2,7WK:]G\!+@_$U0Q!2WP04>↑8"71;0$&70 !%T0"
M DA8P 0F> D3=P,"$+AU?7&=:UW#<->\KD!!<)7K'+X0QC(4-'>2%-MB*E('
MI/Q2/ATYW0%)-=4J>%*9↑A%? F@VT_*HC E[7%G+3*F?F;G311AZPUK"<)G,
MB25?HOWA%*9Z,Z0FX),PL%!D/(0'7>8H0$$[@X_2>)[*9 A1>5J0'%WX0R1T
M,JDYR(%R!3(9'2T*!&@(@\)Z% :2-C)(JF&8</<&!2:0#+GC39Y;_H24HK"%
M+SR: V_A(# 0L.4MIP.CZ,90.0]AQ$YL8-!\/#2&X 47>P;1S!H<N@>TE">K
M;- 7Z-;*@X&$F YK$(-Z+6OBRJSA#7MJU Y T(?HC<%."G,9↑SJ<M9?@(<1P
M$&"+4:SBK,@$QVC0\8R/DI4AOSC&*9AQC5-ZJ\4DV0[L:YD*6M""'XMX?SJ↑
M[&A5 R8X-,I"*%"!E↑&P@A6(↑8>*,G.6T[SF-V,O*W2(LXZUO.8HO@3+=OX>
MB4[BT);U>05@9N)E7;2>,↑0(E@$:BTO@L)ZR0(O"%I8O]GY\AJ4T↑LPH>,N"
MY' &])4!#Z(C=:/<%[T?1WC4I=YQCT'<Z,Z$8'\PD,F/%85!-↑1!QE,>LXG+
M7"(ZG'D/A][?CVN]@V##.2↑?MFS+V(B71L↑A42#XP4M8K ,3\]H,9;A#HP)M
M,4)]F@YP."*ZZ0QDF6@[-:C↑M$RZ_6,5DX%0[-97%H4-[U3'NF5<7C:IQX 3
M-0.YS>0F%;7+2.IK;S7" Q=RKL6&Z83U*(6==DFC'↑T6C_SG/)26PS8[NQYE
M:4G3W↑.TP8():E'[.]3B↑71VT\UJ*JL\<Y5I.;15;6Y5XQS=*:BYL%5>7A02
MM&4N/W?,55WT1=%\ *UF0]RL>Y%_AWKGI>YYJ:F>IJ='/6YO$(,:-&-L=6,=
MYIGY=-C'SA>OVUSJ88 3F70.:[0SO-1P<OO0X4Y(NK]<Z↑A+EU;T_D.5↑]?O
M2D↑[JOU+↑$W#G96*D@/B>;[T4D-↑+HU/.=S!)/+)9[WR*. \T(5>>+BG0?2>
MM_NG3\_+S%M,Y2?A9>H!'WN1NYY4AA?0'$Q8AMF#_C8)X_WM5:/RH-G!]XHO
MM?'=[B)&FOQ$*+>8$:10!)*Q5MA#>$+XDIK3+#0!-BR3 3VQX(0J-,%",_BH
M]LUO(1KD=*HZ.X*%FDKE)PA!"7EC%5&I# 7ML.H&FY1_VF$A.%!5↑#$%KD$R
M.1 ]Y4,%2/ $WW%<U_=#V4<$]Q4#.54%0B %225↑5(8%"+B!295↑5#8$(<B!
MQ↑5↑):A]5* S51 $+:A]QT5_V(<$W9%4↑R=L4" %3\ WJG5< $AEYD,IQU6
M(#1*;Z ;S1(&9R!,#-@=2\!]5&9?,F(A'HA;O!07$=:$%_8]4& $7Z S4% %
M%8*!_ >&3T"&8U@A'JB#8"@$.M,=69 *MA\X38F2:@:!C,&6.$1%>>$5.86
MXI%51]0_VO,_A&A8,Y%M3Q(EY=<$(-!MA)A87T HB↑8D%7=QGO$6'6(Q/78>
M?↑$&+8 12&$'B5$'JE%!T;(D+10]8W$N6D&([?,↑AU@$\J-5BA@#↑8-KEQ@9
M:(0A74$4\0%]+Y [M-7!Q ]IM(&LJA6N"A%KP4"?, '8X)ON'AK4J-]4Y!P
MJH$C4=&,*)"(T+@RW!AIE6%F6N6,NP@"T3B-U3B(S[@_V1<↑Y4A(Z%B(N A8
M[Y@9XK@_\?2(TDB-@LB/\?@D↑/&(Y8A"=D$&]]@R&6>*N-%[U[@_DV47"BDT
MY<AZMB>+H==ZB:B/*)!Q<+"$3?B1(/"%8>@$:R@3V#AQ5%9[ZY:.';F1↑1A8
M(;D4([F%UY:/)XF&:DB&+,F+8E-D1/%\MX(7OD$@HB8LQC@ R&ACP=20X5B3
M↑RB1ZSB/VQ@]7'<&4OF1@3605AE%↑S-<4A!_Y=AT;-"55 F6_<@TW@=↑Y2AZ
M:BD3↑LB6!=E_4D %Y;AV9#>7AO65UKB.]H=_0Z"7T9-WX.B55=F6_VA↑Y7@M
M\>&7=1F88FF0Z]<$Y7AY<B"9@ F/ZV@% B@%Y0A\NX<7G+F8!3D$!YB HYF'
MIVF75PF!MA@]">$C2?B:E"E%#?B 1'"6=2 &F\F1B@F;E7F"Y4@0OQF<,CF<
MN;D_(*B!HFECZ:6<↑$B7G4F05VF#T4EEN24668&;GEF9.]B#22 ↑Y;A\B;F6
MS0D"0YB0;[ H9;0IPEF0[2B0ZPD;3V!?0> $O2@0V64>8\"'9*%&!I-IW(5A
MZY&>D>4&7T @<C":)**@E#@&)%*.FQEA!))5+) 'U3FA)0=F'&JA!&8P9*"A
M'*J.$THB?H8"(2HV: F@ NJ'!6IQT4<J#WF*5ID _*-5E&@'B]589[D4$(F*
M&HIE.CJ5"_H%/GHEC;6B@!8](ND&O)6C.YJD2VI7,= %08IN4IH01<H↑5=JC
M/YJE3KIO/R22/R>+82I72OJC,J"E6HF3:8H'+&"D:\J@5\I8;UJFY3@%WO==
M"4""+J*9,-J'!%IA-'J@WY-QE36?5EI9Y9AQ1X$0L*2A:="A;)JG6Y &<$IE
M>#:ICV2I=2H32"JF3,JI?"HV?,D7A3J@?]B%%I-Q[T$6CFJJ6-JIPH9GL[J3
MHXJBF3JF>05F3TIE&9<&IBAY='JIOHJG/\JI6VJL"9JLO5JJOWJJP?IG681;
M?↑*=>AB@AOJJ-:H:(IE;8U"K;.J@6PH'Y/JER]J@'XJMD8J30YJCU,J@%/J@
M<8IN\\JN]=J@*BJLV>HDI,E[K2JCB J(PB:K>6BN]KH>\?H6>L*P_HJO1Y@\
MNK&'WSJC"'NF2R$&@D$1$EJM=H576↑JQ"TNG1MJNFHI7J4JL2S$&79JC*@NL
M6PJS4\JN,\ND9 JP#VL',;N3<S:)(JNGN/I#>.:S4\JK*=NOFKJG/$M/4C!<
M3- FZ <Y74(F+W M6.M?!L.)!7NH!@JE2R%W.2*<5,23,<"(C$JVS(B+DLBC
M;+HD#ZNU9;N<<,N@=-L&#VL0'TNO0FNO:-"W_2D9'A(5M4(F7PNNBFHQ8V '
M<\"VPDE;3" _252+*8 'NU%BNBB-,V&FV+.V5UNWA1A/;B(_AB@RB(B+5Q2P
MD;&5B:NQL&JC2[&5PFD797$&J1$4_O41MVBEB_6P<R P:>(C$NNX\#6X&DD'
M+P"3KWNPL2NN8VLU$FL&Z9:O%B$P_/JW7T"]+9NPL↑L3FI%D=IND L9*:+"E
MY1N↑V7NWE 6↑!M&]'(MN) FT[9J33+@↑↑6J_)8FRF,J@↑NL13UNQNP><S1NV
M+ILOR2FQ TRQWJLH9F &>":QY '!2S&X/X>'NA&N8↑*N<F A#'H1<N$"#/IC
MDN8"/\;!T6.O).+!7P#";R#"7T#"E6'";#"Q8L.*G;9(>?B\&[PD+.S",-Q<
M;F'":=#";@$Y:/)<SJ?!>)O$;7 C1AS"(YRW)FP&V↑O$8L.U *;#&;RXI *X
M?0O%0#S"_F7"8]"@@9N'+JH758?!\>7%W4A9>O'#;B#%,6Q=)EP9<BP'*;S'
MPBO&=?S"(XS'!$$'7R"\TH4&5EM@L,C%;]S'U$O'=HP'U*L75;R]<-#'Z6L0
M@#S)E2P'E[S)BAR(7_"_G2S(,?S)E_R_8J.9RRMV9.?&/(RGE27)J(P'D&?"
M=D!9\-7'>6K+09S+N$Q75↑*BR2G+3$Q9R0G,@YR<>:S,P-G'$XQGIQS$"_S,
MT[P48N-\UE4'?$&PI$$H#]/-K.I\>\!7D$ N\N@A+(#↑85&AK3#I-%7ZCR=
M&SR_[BQ*6LB$.9$1@$C/=I$@&!'((-!A↑36OIY, Y.P2,NP2>Y!?%↑Q\,!%,
M3:*CZ;S0R'S"#NK.OO@C#KJ*;M&*"F#1!(#12ZS1),+1 D$V]PK27DL:"= '
M&]S0.↑ 4&"W$#IU?.,PC2_P@)$VZ(S,01;PD↑1P9.TT7" W3,CW"1&W3>N'-
M#)VW!:W/4MW33D'/'.4F V'%>5O41N/$()#4/KW4J>S$-3W2-[V[#ZW/6NRU
M5CW2]"PF>'#&?)N'7NTOT]FU/-*W"4W6<SV=9ZW03\VJA4P7:]VZ; PM;TW2
M<JW'B.PC=↑VZC[TP/@W0';$2N8O7):=F>FQ=*BT9B8THC=S7,↑W93BT'4+W5
M<* 74TW55N/2/"W/E9W.4&)?'T')F'S79'.]9"8M(DW2"I.%N"W*=RT@;[ &
M87 0(J+9_↑6UM%(G=\(E @.(P(T&PFW%_WO7HK?/7*C4,_W)@7W3D-?:D4&H
MBQW7F3+,E777A%I9"4W/)BW/:K;+B_79A+I8I#W"D!?>@\W0"TS>Y)6<6?O?
MYWW1_8W,=#99"RP_44;5!P):L,T\LTT C?T%V4P'=WWAFJ(H!N(6[97?=YR<
M9TW/9.W"9RW33B";+* "DGO6+K)&;60>43$@ID(7GR4:"8:)L,OA5',G@_(C
M[OUQDE$&< 1I3/Q&C3I8501?Y($"9"5$.Y,"*Q".3.13*: "E=7D\4T1GOL]
MCDOD24ZJ66X&*'!)935$4D[E<*6+6,[D9"ZYK"L0F<CCGJ(5&I<3>8!@[LWA
MYW$'<Q$4[JW!8J H=\#+0N)02#0 @_588XX"< XZF_L"0"(D30[G@\O-1/Y(
MH(W:WXP7IR/.6V/2KY0IYZP \'W@'9'I1CY7_?;9_2;+HQY+Z$P MHO9<"$F
M<[7>↑DQ*\8Q(FC)":1'KIW/JG#XM.ZQ8.ML%GRWL↑$T:* Y60↑3B3M+>JIXI
M"PW.#P+JY8'17U[DI#[KW"[L*N"X7]#JNWYJ+D'MWB[KII[.DOL1Y&X&>%$&
M=_WJ\EX&JB$@2ID@%P'L'B'N#T+/[S[NDQ5GNGT2:23LH8<;'I<:32+PI\0$
M83U9P!K9U>X2S?X@,FWF4$X%TCXO#YX@-SX?U↑[IX2P>XWS@I4[/NZL"#E/N
M4_K99A#R\Q&SP↑[N$?\2+D\&T/R@,N;@;H @\P%+<K 3YW(Z,FT$26.!1O#Q
M H'N6B&EI3@Z[37=IP/U<G 6 ↑]E1+9B,Z;/138D88VCH&TPE4,:6*_U.6]P
M+F;P[XSP_X'0"\)@5X]J40\Q:[]F,Y;.!TWV<U\YHXWV=I_U&VYBS)9?&Z?I
M@F$7LR)"8V!">)$I&H04I.$B:5\@HE(NJN$>$"=AH27XG*CV↑J%?#G?7$QU:
MF,NA=1_Z>#_Z/P9+L=C@↑@S[(2(9>6!>E/\@:=_Z$L]I./DG<O;9&3="JH'0
M0IY;BA0>JW_W[]ZX:"EC(,#6=2YR .*Z?&[[N+_\A-_\CAO:T"_]>F+GU1_:
MVB_Z$M↑XD!MET1\9>;(G=\ZVY<_[_F('>0O]D' X._↑ "+5H,_\.=↑XAZ?↑
M↑=7↑XG\>;2W2N\_] XL7/\_↑T]\I%RLTYG$6QJ>)YS&P)J_[@V_↑\U↑;UEVB
MLL_↑T]\I%RLTYG$6QJ>)YU&;UATSNC_XYC__"_SS↑2_↑YS'S00_A2Y)"U77,
M_;_]_V\'J"?[[#_][__:H\WG9P'=DY:%_;_]_V\'W3D6O=?@[#_]=TZN74&P
MU]↑=8_'("K#[[YX:=T"[#<[↑U89@H'B'KMO_VY_SJ>'GL,P7/\_↑U89@H'B'
MJ\KNN__NJ7$'FOGS[%]M" :*=TBH_;_].9\:=]"W/\_6U89@H'B'?+VJ[+[[
M[YX:=Y GY5('GO_S[%]M" :*=Y@GY5('GN\?L,RJ_;_].9\:=R#O-RO[[%]M
M" :*=VA\:? G;J#I\CZE\?_NJ7$'C/3S;%UM" :*=_C6N__NN_:>X"9NLA\9
MIIF%(L!K<7&'B0]+<R "\?_N]28B↑-;@D6&:62@"=_ G D5J'.<2A"("\=_\
M)@3=97?7P\_2D ]IT#UI6=C_V___)@0HZ'8G/Q\9P\_2D ]I@()NT;W=E:\
M&@ :"%A30TA%344N3$Y+ %VA ]1"Q7H:ZW@ PO\( 8HX,+G3IRQ+P9
MPX5-&C%<QL!@X↑*-@5C10@&?.EVI0!T7',FS8DYY 1B;*C&3IAQ*1,
MXR8-G8P;.]*\J?--2HL8.\*1LS.EG#)AR*2<DZ?E'#-UW,3 R?%I5!DIVX2A
M@V:FUC,CV\R9<]",F9P>08I$↑S%DF8T$#2)4R- AQ)!U!A8\F'!APX=<M')E
MHU=NW[J Q[#9N%$#&@A84T-/32Y# $Q.2P!=C3D $42#)ZOP2R( ,+U2
MP#-GS)LV+L: : $B#(@Y:=K 85/FX1@T9=I4%).'3AF#9"H:E)B&HAP0*EXT
M4! PP9 W</+(27,T0*,:D !$C!PX<+$!P!$$DC)TT9$ T27,Q3!DV((24
MH:-G98(@;*!*H6ES#@@I9>:4D6.G#!FK4,:V23,'XALW(-B".",GC!N/2<V\
M.5G'C9RP=&:.P0O"S=L6(S7*&9,F#-0Z8A.D7+ER1!HW8]C4"0E"!,&+&<NX
M0".B\N7,FRMZGB,&I&C2E%D*A*BGXALS(%P+K6/&S%B4*A6,"&GF<L4A38)@
M24 #!J0!L0/F?DOG<ITPU=↑"H),'3EC@E8D;!S'DBY0B5*I(<9*@18SP98J[
M.?[%21$L5!*TEQ%=8)LP8\CQQG8#@C;&&B#H=9)#;(31AAAD,,C636N4D<<=
M>R4UF7#BS0="@P]&6&$>*."10@(HE+A3#SU\N,87,&7GAF,@\,$'3B:"P**+
M7_PU!QTI] ="&7AX),>,4-D1QDQAB$&15QL2:21<3%@1!!,\QIC&6XZQP,:+
M/M+!0F!UE+&#D&R\,0:-2C+IY'<;_H@=4R!4>65<;NBU@W[2C01'2;]=IA=X
M"JS4YQN<B<&;;R?%2<><"O4%T1GS)=7426,HVML6R"G7Q9[2B1&&6"#<-EVB
MB_[F**1XWI3IJ&8F\%RHL":X5VYUR/'770GV-=B6<*U:G4*7N0I'8'O.*I!N
MFC(* AQO%*MJ<(8*I. =2R854F9+SOD6E,$5"P(9;WS181DHI, "N5↑(14>Z
MZY8;1QUO> 0ONR!"&,:]Y1KD1EN!E>$@O↑8↑%0:)*9RI@+CX3D4P10&/\?!4
M<LI!L+]D$&Q7QNJRNU>Z"C-<;AIF$"Q&&6=<1O =: "J\1ACA#4'R"O9B>5_
M%7[A&HQBJ/'1NPD+*2U=35+4*V8R;E=T11MRYQUQ#Y$Y& A[Y(;&DBC=]<6,
M&NW0:F%TZ(QH&2QHO>09<WC=!PA.4$%$$48H+.>P;+L-=];'RE'VHV)LT86.
M5%LE0A!4/-&$""S(.L 34'Q!N.&)Q\""X$5$\0/BBC/↑1>6))R##Y HD(((3
M53#!Q.6=:TZZZ9&#+KH33U"!↑7.JE\Y$ZX(/\8034\R↑>..Z\Y[XY[D'(87O
MF@]A?.>2YT[$\8G3#OSSS+LNPA3HM:"\%"%@GH#FV%.Q_?#6AZ_]\]VGWGCX
M0U#ON?4K(-]X$$00T7D+Q(<N0@OR?S%%%4*X7_Y$IX+↑-:%T K1>%*H0NR04
MH6W>T]P"GY! P?&@?TR8PA0JJ+\>]*]RM],/_JSG@_X=@0I2X& "8+"2/BBL
M6@_Q#F-HI* V*.U-A'*:6>(3-3G486I5NQ1*S! VKIGI:RA0 1&_8(8QN"$%
M( /!VHQ@M[BM9&YTHN+;C##$O+& B$WR&↑#V(+@)4J$(F&/7O.I%-L$Q(0A-
M$ (1@I#&<N4K0M9[VQNS4,>"-2@/UF,">KS7,#&Y$3T%[%PA*Q9(])QG"'V$
MV%_&D$>X)<$↑?3Q7↑="3/OVPRUW62X(1"#DR,U@O>$0@I=C<0 ;K":$(1[AD
M'T↑6,C=L<H$/' (:$\<N6E[&>D%P0BH56:Z-6>\)T/-DN?9BO2L@(0
∂31-Aug-89 0542 ramsdell@linus.mitre.org Re: Multiple values for R4RS
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 31 Aug 89 05:42:24 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA02306; Thu, 31 Aug 89 08:20:06 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA26653; Thu, 31 Aug 89 08:20:36 EDT
Posted-Date: Thu, 31 Aug 89 08:13:52 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA03764; Thu, 31 Aug 89 08:13:53 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8908311213.AA03764@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Subject: Re: Multiple values for R4RS
In-Reply-To: Your message of Wed, 30 Aug 89 16:56:19 -0500.
<8908302155.AA07362@life.ai.mit.edu>
Date: Thu, 31 Aug 89 08:13:52 EDT
>> From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
...
>> I now see that there is some value in requiring "(values e)" to be the
>> same as "e", even in the absense of the infamous "truncation" feature.
>> There is also some value in requiring (or allowing) "(values e)" to be
>> distinct from "e". I see the latter as simpler, not more eomplex, both
>> in terms of the semantics and in terms of the implementation. However,
>> as I said at Snowbird, I am willing to defer to the judgement of the
>> majority on this issue.
>>
>> Kent
This confirms my hope that there is good chance we can reach agreement
on the subject of multiple values for R4RS. Let me point out that if
agreement is reached soon enough, multiple values could be made part
of IEEE Draft Standard for the Scheme Programming Language.
Before I submit the proposal, I ask for editorial suggestions,
especially to the sentence:
Within procedure 'generator', the initial escape procedure returned
by call-with-current-continuation is like 'receiver' except that
this escape procedure's continuation is the one that was in effect
when the evaluation of the with-values expression began (see
call-with-current-continuation).
How about this?
When procedure 'generator' is called, capturing its initial continuation
with call-with-current-continuation produces an escape procedure which
is like 'receiver' except that this escape procedure's continuation
is the one that was in effect when the evaluation of the with-values
expression began (see call-with-current-continuation).
Here is attempt at the changes required in
call-with-current-continuation.
Replace the last sentence in the first paragraph with:
The escape procedure is a Scheme procedure which when called, will
ignore whatever continuation is in effect at that later time and will
give its arguments to the continuation that was in effect when the
escape procedure was created. Within a with-values expression, the
arity of the escape procedure which packages the continuation in
effect when the generator is called must match that of the receiver.
All other escape procedures must accept at least one argument. Some
implementions may choose to ignore extra arguments, others may signal
an error when more then one argument is given.
John
∂31-Aug-89 1103 ramsdell@linus.mitre.org Multiple values not for R4RS
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 31 Aug 89 11:02:47 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA04321; Thu, 31 Aug 89 13:08:03 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA00180; Thu, 31 Aug 89 13:09:00 EDT
Posted-Date: Thu, 31 Aug 89 13:02:15 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA04528; Thu, 31 Aug 89 13:02:17 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8908311702.AA04528@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Cc: ramsdell@linus.mitre.org
Subject: Multiple values not for R4RS
In-Reply-To: Your message of Thu, 31 Aug 89 09:20:53 -0700.
<8908311620.AA26072@Polya.Stanford.EDU>
Date: Thu, 31 Aug 89 13:02:15 EDT
Well I guess now the focus is to generate a proposal in preparation
for the next Scheme meeting. Hopefully, the proposal presented at the
meeting will have been agreed to by those reachable by E-mail. It
sounds like those interested in records are following the same plan.
R4RS just is not going to have multiple values. Let's make sure R5RS
does.
>> From: Morris J. Katz <katz@Polya.Stanford.EDU>
...
>> The escape procedure is a Scheme procedure which when applied to a
>> value(s) will ignore whatever continuation is in effect at the time of
>> application and will instead give its argument(s) to the continuation
>> that was in effect when the escape procedure was created. The arity
>> of an escape procedure created in the 'generator' position of a
>> 'with-values' form must match that of the 'receiver'. All other
>> escape procedures must accept at least one argument. Some
>> implementions may choose to ignore extra arguments, others may signal
>> an error when more then one argument is given.
...
Morry, I think your wording is better than my attempt, but how about
this small modification?
The escape procedure is a Scheme procedure which when applied to some
values will ignore whatever continuation is in effect at the time of
application and will instead give its arguments to the continuation
that was in effect when the escape procedure was created. The arity
of an escape procedure created in the 'generator' position of a
'with-values' form must match that of the 'receiver'. All other
escape procedures must accept at least one argument. Some
implementions may choose to ignore extra arguments, others may signal
an error when more then one argument is given.
I am not happy with Morry's rewording of the description of
with-values. Any more suggestions?
John
PS. The intended formal description of with-values is:
%%% Raw TeX.
$$\hbox{\it with-values} = \hbox{\it twoarg }(\lambda \epsilon_1
\epsilon_2\kappa . \hbox{ \it applicate } \epsilon_1 \langle \rangle
\lambda \epsilon↑\star . \hbox{ \it applicate } \epsilon_2
\epsilon↑\star \kappa)$$
\end
∂31-Aug-89 1106 dyb@iuvax.cs.indiana.edu Re: Multiple values for R4RS
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 31 Aug 89 11:06:21 PDT
Received: from iuvax.cs.indiana.edu by life.ai.mit.edu (4.1/AI-4.10) id AA04445; Thu, 31 Aug 89 13:24:58 EDT
Message-Id: <8908311724.AA04445@life.ai.mit.edu>
Received: by iuvax.cs.indiana.edu
Date: Thu, 31 Aug 89 10:11:18 -0500
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
To: ramsdell@linus.mitre.org, rrrs-authors@life.ai.mit.edu
Subject: Re: Multiple values for R4RS
> From ramsdell@linus.mitre.org Thu Aug 31 07:35:26 1989
> Subject: Re: Multiple values for R4RS
>
> This confirms my hope that there is good chance we can reach agreement
> on the subject of multiple values for R4RS. Let me point out that if
> agreement is reached soon enough, multiple values could be made part
> of IEEE Draft Standard for the Scheme Programming Language.
I don't see how. We agreed at Snowbird not to make any significant
changes to R4RS via email that weren't preapproved at Snowbird, and we
specifically left multiple values as an issue to be decided at the next
meeting. So multiple values must wait until R5RS or we must delay R4RS
until after we meet again. Either way, multiple values won't make the
IEEE draft standard, right?
∂31-Aug-89 1111 katz@polya.stanford.edu Multiple values for R4RS
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 31 Aug 89 11:11:07 PDT
Received: from Polya.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA04411; Thu, 31 Aug 89 13:22:30 EDT
Received: by Polya.Stanford.EDU (5.61/25-eef) id AA26072; Thu, 31 Aug 89 09:20:53 -0700
Date: Thu, 31 Aug 89 09:20:53 -0700
From: Morris J. Katz <katz@polya.stanford.edu>
Message-Id: <8908311620.AA26072@Polya.Stanford.EDU>
To: ramsdell@linus.mitre.org
Cc: rrrs-authors@life.ai.mit.edu
In-Reply-To: ramsdell@linus.mitre.org's message of Thu, 31 Aug 89 08:13:52 EDT <8908311213.AA03764@huxley.mitre.org>
Subject: Multiple values for R4RS
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Posted-Date: Thu, 31 Aug 89 08:13:52 EDT
From: ramsdell@linus.mitre.org
Date: Thu, 31 Aug 89 08:13:52 EDT
Here is attempt at the changes required in
call-with-current-continuation.
Replace the last sentence in the first paragraph with:
The escape procedure is a Scheme procedure which when called, will
ignore whatever continuation is in effect at that later time and will
give its arguments to the continuation that was in effect when the
escape procedure was created. Within a with-values expression, the
arity of the escape procedure which packages the continuation in
effect when the generator is called must match that of the receiver.
All other escape procedures must accept at least one argument. Some
implementions may choose to ignore extra arguments, others may signal
an error when more then one argument is given.
Once again I will try my hand at an alternative set of prose.
The escape procedure is a Scheme procedure which when applied to a
value(s) will ignore whatever continuation is in effect at the time of
application and will instead give its argument(s) to the continuation
that was in effect when the escape procedure was created. The arity
of an escape procedure created in the 'generator' position of a
'with-values' form must match that of the 'receiver'. All other
escape procedures must accept at least one argument. Some
implementions may choose to ignore extra arguments, others may signal
an error when more then one argument is given.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂31-Aug-89 1121 ramsdell@linus.mitre.org Re: Multiple values for R4RS
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 31 Aug 89 11:20:51 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA03732; Thu, 31 Aug 89 11:47:31 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA29266; Thu, 31 Aug 89 11:48:30 EDT
Posted-Date: Thu, 31 Aug 89 11:41:45 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA04414; Thu, 31 Aug 89 11:41:47 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8908311541.AA04414@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Subject: Re: Multiple values for R4RS
In-Reply-To: Your message of Thu, 31 Aug 89 10:11:18 -0500.
<8908311511.AA28731@linus.MITRE.ORG>
Date: Thu, 31 Aug 89 11:41:45 EDT
>> From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
>>
>> > From ramsdell@linus.mitre.org Thu Aug 31 07:35:26 1989
>> > Subject: Re: Multiple values for R4RS
>> >
>> > This confirms my hope that there is good chance we can reach agreement
>> > on the subject of multiple values for R4RS. Let me point out that if
>> > agreement is reached soon enough, multiple values could be made part
>> > of IEEE Draft Standard for the Scheme Programming Language.
>>
>> I don't see how. We agreed at Snowbird not to make any significant
>> changes to R4RS via email that weren't preapproved at Snowbird, and we
>> specifically left multiple values as an issue to be decided at the next
>> meeting. So multiple values must wait until R5RS or we must delay R4RS
>> until after we meet again. Either way, multiple values won't make the
>> IEEE draft standard, right?
At the very least, we can prepare a proposal for the next meeting
which is agreeable to all reachable by E-mail. It seems too bad no
action can be taken on a subject on which there seems to be near
agreement. Is that what you really want?
John
PS. In case my words are describing WITH-VALUES are confusing, here
is a formal description of my intended semantics.
%%% Raw TeX.
$$\hbox{\it with-values} = \hbox{\it twoarg }(\lambda \epsilon_1
\epsilon_2\kappa . \hbox{ \it applicate } \epsilon_1 \langle \rangle
\lambda \epsilon↑\star . \hbox{ \it applicate } \epsilon_2
\epsilon↑\star \kappa)$$
\end
∂31-Aug-89 1134 katz@polya.stanford.edu Revised multiple values and call/cc.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 31 Aug 89 11:33:47 PDT
Received: from Polya.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA04621; Thu, 31 Aug 89 13:33:23 EDT
Received: by Polya.Stanford.EDU (5.61/25-eef) id AA25497; Thu, 31 Aug 89 09:01:12 -0700
Date: Thu, 31 Aug 89 09:01:12 -0700
From: Morris J. Katz <katz@polya.stanford.edu>
Message-Id: <8908311601.AA25497@Polya.Stanford.EDU>
To: ramsdell@linus.mitre.org
Cc: rrrs-authors@life.ai.mit.edu, ramsdell@linus.mitre.org
In-Reply-To: ramsdell@linus.mitre.org's message of Wed, 30 Aug 89 15:39:08 EDT <8908301939.AA02909@huxley.mitre.org>
Subject: Revised multiple values and call/cc.
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Posted-Date: Wed, 30 Aug 89 15:39:08 EDT
From: ramsdell@linus.mitre.org
Date: Wed, 30 Aug 89 15:39:08 EDT
Let me revise the proposal by substituting
Within procedure 'generator', the initial escape procedure returned
by call-with-current-continuation is like 'receiver' except that
this escape procedure's continuation is the one that was in effect
when the evaluation of the with-values expression began (see
call-with-current-continuation).
for
Within procedure 'generator', the initial escape procedure returned
by call-with-current-continuation is 'receiver'.
I find the new proposed wording somewhat opaque and have therefore
tried my hand at prose as well.
During the evaluation of a 'with-values' form, the 'generator' thunk
is first thawed (evaluated to yield some values) and then the 'receiver' is
applied to the values returned by 'generator'. This means that a
continuation captured in 'generator' includes the application of
'receiver' to the values returned by 'generator'. It also includes the
return from 'with-values' of the value(s) returned by 'receiver'.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂31-Aug-89 2019 @spencer.cs.uoregon.edu:will@cs.uoregon.edu Re: Multiple values not for R4RS
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 31 Aug 89 20:19:12 PDT
Received: from skinner.cs.uoregon.edu by life.ai.mit.edu (4.1/AI-4.10) id AA10140; Thu, 31 Aug 89 22:58:47 EDT
Received: from spencer.cs.uoregon.edu by skinner.cs.uoregon.edu with SMTP
(5.59++/IDA-1.2.8) id AA29911; Thu, 31 Aug 89 15:10:16 PDT
Received: by spencer.cs.uoregon.edu; Thu, 31 Aug 89 15:10:00 PDT
Date: Thu, 31 Aug 89 15:10:00 PDT
From: will@cs.uoregon.edu
Message-Id: <8908312210.AA04962@spencer.cs.uoregon.edu>
To: rrrs-authors@life.ai.mit.edu
Subject: Re: Multiple values not for R4RS
Cc: ramsdell@linus.mitre.org
You shouldn't have to worry so much about the wording, since that can
be left to whoever edits the R5RS.
Congratulations: you have reached consensus on multiple values. Now
all you have to do is to maintain that consensus until the next meeting
and to agree on the name of WITH-VALUES, RECEIVE-VALUES, CALL-WITH-VALUES,
whatever.
Summary of consensus: the VALUES procedure takes any number of arguments,
and simply passes them to its continuation. A procedure to be named
later takes a thunk and a procedure, and calls the thunk with a
continuation that, when passed some values, calls the procedure that
was the second argument to the procedure to be named later with those
values as arguments. Except for continuations created by the procedure
to be named later, all continuations take exactly one value, as now;
the effect of passing no value or more than one value to continuations
that were not created by the procedure to be named later is unspecified
(as indeed it is unspecified now).
Peace, Will
∂31-Aug-89 2026 katz@polya.stanford.edu Multiple values not for R4RS
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 31 Aug 89 20:26:14 PDT
Received: from Polya.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA10285; Thu, 31 Aug 89 23:05:30 EDT
Received: by Polya.Stanford.EDU (5.61/25-eef) id AA05748; Thu, 31 Aug 89 13:17:44 -0700
Date: Thu, 31 Aug 89 13:17:44 -0700
From: Morris J. Katz <katz@polya.stanford.edu>
Message-Id: <8908312017.AA05748@Polya.Stanford.EDU>
To: ramsdell@linus.mitre.org
Cc: rrrs-authors@life.ai.mit.edu, ramsdell@linus.mitre.org
In-Reply-To: ramsdell@linus.mitre.org's message of Thu, 31 Aug 89 13:02:15 EDT <8908311702.AA04528@huxley.mitre.org>
Subject: Multiple values not for R4RS
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Posted-Date: Thu, 31 Aug 89 13:02:15 EDT
From: ramsdell@linus.mitre.org
Date: Thu, 31 Aug 89 13:02:15 EDT
Morry, I think your wording is better than my attempt, but how about
this small modification?
I only used the phraseology "value(s)" for pedantic reasons. If
people generally feel that the implications are obvious without being
quite as pedantic, I am perfectly happy with your reworking of my
wording.
I am not happy with Morry's rewording of the description of
with-values. Any more suggestions?
If it is possible, I would be interested in what about my wording you
find troubling. (I realize that often bad feelings about wordings are
based on gut level feelings that are hard to explain.) Given some
input, I would be happy to work on refining my prose.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂01-Sep-89 0001 Pavel.pa@xerox.com An alternate description of the multiple values proposal
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Sep 89 00:00:36 PDT
Received: from Xerox.COM by life.ai.mit.edu (4.1/AI-4.10) id AA00226; Fri, 1 Sep 89 02:52:08 EDT
Received: from Salvador.ms by ArpaGateway.ms ; 31 AUG 89 12:51:32 PDT
Date: Thu, 31 Aug 89 12:51:32 PDT
From: Pavel.pa@xerox.com
Subject: An alternate description of the multiple values proposal
To: rrrs-authors@life.ai.mit.edu
Cc: Pavel.pa@xerox.com
Message-Id: <890831-125133-8085@Xerox>
As I said in my last message on this topic, I'm pretty unsatisfied with the
descriptions that have been circulated thus far. Unfortunately, my
proposed description in that message seems to have been ignored, so I'll
repeat it here in the context of a complete proposed description of the
facility, including the write-ups of VALUES, CALL-WITH-VALUES, and
CALL-WITH-CURRENT-CONTINUATION.
I like this wording much more than the others presented so far because it
seems much clearer to me. The others have all been too vague or opaque for
my taste; in particular, none of them say anything about the legality of
returning other than one value to ``for effect'' context. Some of the
earlier descriptions also use the wording ``a `with-values' form'' or ``a
`with-values' expression''; this is misleading, since WITH-VALUES (or
CALL-WITH-VALUES) is a procedure, not a syntactic keyword.
I would appreciate hearing any comments on the description below.
Pavel
====================
(VALUES obj ...) [Procedure]
Returns all of the arguments, in the order given. VALUES could be
implemented as follows:
(define values
(lambda args
(call-with-current-continuation
(lambda (k)
(apply k args)))))
See the description of CALL-WITH-CURRENT-CONTINUATION for a discussion of
the number of values accepted by various contexts.
(CALL-WITH-VALUES producer consumer) [Procedure]
Producer should be a procedure of zero arguments and consumer should be a
procedure. Consumer is applied to the value(s) returned by invoking
producer. CALL-WITH-VALUES returns the result(s) of the invocation of
consumer.
(CALL-WITH-CURRENT-CONTINUATION proc) [Procedure]
Proc must be a procedure of one argument. The procedure
CALL-WITH-CURRENT-CONTINUATION packages up the current continuation as an
``escape procedure'' and passes it as an argument to proc. The escape
procedure is a Scheme procedure that when applied, ignores the continuation
in effect at that time and instead gives its argument(s) to the
continuation that was in effect when the escape procedure was created.
The number of arguments accepted by an escape procedure depends upon the
continuation in effect when the escape procedure was created. There are
six contexts in which continuations can be captured in Scheme:
1. the operator position of a procedure call,
2. an operand position of a procedure call,
3. the test position of a conditional,
4. the expression in an assignment,
5. any but the last expression in the body of a lambda expression, and
6. the invocation of the producer argument to CALL-WITH-VALUES.
Escape procedures created in any of the first four contexts accept at least
one argument; the effect of applying them to more than one value is
unspecified. In some implementations, an error is signalled; in some
others, the extra values are ignored.
Escape procedures created in the fifth context above ignore any arguments
passed to them and so accept any number of values, including zero.
An escape procedure created in the final context above accepts exactly as
many arguments as are accepted by the consumer procedure in that invocation
of CALL-WITH-VALUES.
∂01-Sep-89 0052 @mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu Programmer-defined data types, version 2
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Sep 89 00:52:09 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA00439; Fri, 1 Sep 89 03:43:12 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa03329;
31 Aug 89 15:55 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 31 Aug 89 15:55:39 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa02540;
31 Aug 89 14:47 EDT
Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA05616; Thu, 31 Aug 89 14:45:51 EDT
Received: from localhost by zurich.ai.mit.edu; Thu, 31 Aug 89 14:42:33 edt
Date: Thu, 31 Aug 89 14:42:33 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
Message-Id: <8908311842.AA05074@zurich.ai.mit.edu>
To: katz@polya.stanford.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: "Morris J. Katz"'s message of Wed, 30 Aug 89 12:02:13 -0700 <8908301902.AA20609@Polya.Stanford.EDU>
Subject: Programmer-defined data types, version 2
Date: Wed, 30 Aug 89 12:02:13 -0700
From: "Morris J. Katz" <katz@polya.stanford.edu>
For aesthetic reasons I would prefer to see
(MAKE-RECORD-TYPE type-name . field-names)
rather than
(MAKE-RECORD-TYPE type-name field-names)
as the for for MAKE-RECORD-TYPE.
How do others feel?
I prefer having a single argument which is a list. Not only does this
reduce the number of characters that must be typed, but it simplifies
abstraction on the `field-names' argument, and leaves the argument
list open for adding arguments in the future.
∂01-Sep-89 0054 @mc.lcs.mit.edu,@life.ai.mit.edu:jar@zurich.ai.mit.edu Programmer-defined data types, version 2
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Sep 89 00:54:24 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA00440; Fri, 1 Sep 89 03:44:33 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa07773;
31 Aug 89 22:04 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 31 Aug 89 22:04:23 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa07614;
31 Aug 89 21:48 EDT
Received: from zurich.ai.mit.edu ([18.43.0.158]) by life.ai.mit.edu (4.1/AI-4.10) id AA09401; Thu, 31 Aug 89 21:46:38 EDT
Received: from localhost by zurich.ai.mit.edu; Thu, 31 Aug 89 21:43:24 edt
Date: Thu, 31 Aug 89 21:43:24 edt
From: Jonathan Rees <jar@zurich.ai.mit.edu>
Message-Id: <8909010143.AA19695@zurich.ai.mit.edu>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Pavel.pa@xerox.com's message of Tue, 29 Aug 89 18:29:19 PDT <890829-184715-4408@Xerox>
Subject: Programmer-defined data types, version 2
I endorse version 2 and all your replies to everyone, with one very
minor nit: allowing RECORD-TYPE-FIELD-NAMES to return a permutation of
the original argument to MAKE-RECORD-TYPE feels inconsistent with
making optional the list-of-field-names argument to
MAKE-RECORD-CONSTRUCTOR. The original ordering of the list must be
remembered, in case someone omits the argument to
MAKE-RECORD-CONSTRUCTOR, so why should a Scheme system gratuitously
refuse to cough it up? The order might be of some interest to, say, a
portable inspector. But I don't feel at all strongly about this.
Jonathan
∂01-Sep-89 0259 @mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu Programmer-defined data types, version 2
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Sep 89 02:59:07 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA01182; Fri, 1 Sep 89 05:49:55 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa06292;
31 Aug 89 20:03 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 31 Aug 89 20:03:47 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa05061;
31 Aug 89 18:20 EDT
Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA07566; Thu, 31 Aug 89 18:19:03 EDT
Received: from localhost by zurich.ai.mit.edu; Thu, 31 Aug 89 18:15:50 edt
Date: Thu, 31 Aug 89 18:15:50 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
Message-Id: <8908312215.AA07597@zurich.ai.mit.edu>
To: katz@polya.stanford.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Morris J. Katz's message of Thu, 31 Aug 89 13:26:10 -0700 <8908312026.AA06068@Polya.Stanford.EDU>
Subject: Programmer-defined data types, version 2
Date: Thu, 31 Aug 89 13:26:10 -0700
From: Morris J. Katz <katz@Polya.Stanford.EDU>
Date: Thu, 31 Aug 89 14:42:33 edt
From: cph@zurich.ai.mit.edu (Chris Hanson)
Date: Wed, 30 Aug 89 12:02:13 -0700
From: "Morris J. Katz" <katz@polya.stanford.edu>
For aesthetic reasons I would prefer to see
(MAKE-RECORD-TYPE type-name . field-names)
rather than
(MAKE-RECORD-TYPE type-name field-names)
as the for for MAKE-RECORD-TYPE.
How do others feel?
I prefer having a single argument which is a list. Not only does this
reduce the number of characters that must be typed, but it simplifies
abstraction on the `field-names' argument, and leaves the argument
list open for adding arguments in the future.
I might be swayed that it is important to leave the rest argument
position open for future extensions; but, I hardly buy that the
trade-off between 3 characters to form the list and one character per
symbol to make it into a symbol represents enough of a difference in
keystrokes to be important. (My approach is actually shorter for
records of 1 or 2 fields (-:)
Since I was obviously making an aesthetic argument, let's just
summarize by saying I prefer the aesthetics of a single list argument.
(I notice that you said nothing about my "abstraction" argument.)
∂01-Sep-89 0304 @mc.lcs.mit.edu,@life.ai.mit.edu:katz@polya.stanford.edu Programmer-defined data types, version 2
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Sep 89 03:04:06 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA01223; Fri, 1 Sep 89 05:54:31 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa09165;
1 Sep 89 0:01 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 1 Sep 89 00:01:30 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa09029;
31 Aug 89 23:57 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA07442; Thu, 31 Aug 89 18:12:19 EDT
Received: from Polya.Stanford.EDU (polya.stanford.edu) by zurich.ai.mit.edu; Thu, 31 Aug 89 17:52:09 edt
Received: by Polya.Stanford.EDU (5.61/25-eef) id AA06068; Thu, 31 Aug 89 13:26:10 -0700
Date: Thu, 31 Aug 89 13:26:10 -0700
From: "Morris J. Katz" <katz@polya.stanford.edu>
Message-Id: <8908312026.AA06068@Polya.Stanford.EDU>
To: cph@zurich.ai.mit.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Chris Hanson's message of Thu, 31 Aug 89 14:42:33 edt <8908311842.AA05074@zurich.ai.mit.edu>
Subject: Programmer-defined data types, version 2
Date: Thu, 31 Aug 89 14:42:33 edt
From: cph@zurich.ai.mit.edu (Chris Hanson)
Date: Wed, 30 Aug 89 12:02:13 -0700
From: "Morris J. Katz" <katz@polya.stanford.edu>
For aesthetic reasons I would prefer to see
(MAKE-RECORD-TYPE type-name . field-names)
rather than
(MAKE-RECORD-TYPE type-name field-names)
as the for for MAKE-RECORD-TYPE.
How do others feel?
I prefer having a single argument which is a list. Not only does this
reduce the number of characters that must be typed, but it simplifies
abstraction on the `field-names' argument, and leaves the argument
list open for adding arguments in the future.
I might be swayed that it is important to leave the rest argument
position open for future extensions; but, I hardly buy that the
trade-off between 3 characters to form the list and one character per
symbol to make it into a symbol represents enough of a difference in
keystrokes to be important. (My approach is actually shorter for
records of 1 or 2 fields (-:)
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂01-Sep-89 0333 jinx@zurich.ai.mit.edu An alternate description of the multiple values proposal
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Sep 89 03:33:37 PDT
Received: from zurich.ai.mit.edu ([18.43.0.171]) by life.ai.mit.edu (4.1/AI-4.10) id AA01454; Fri, 1 Sep 89 06:26:25 EDT
Received: from localhost by zurich.ai.mit.edu; Fri, 1 Sep 89 06:23:14 edt
Date: Fri, 1 Sep 89 06:23:14 edt
From: jinx@zurich.ai.mit.edu (Guillermo J. Rozas)
Message-Id: <8909011023.AA11008@zurich.ai.mit.edu>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@life.ai.mit.edu, Pavel.pa@xerox.com
In-Reply-To: Pavel.pa@xerox.com's message of Thu, 31 Aug 89 12:51:32 PDT <890831-125133-8085@Xerox>
Subject: An alternate description of the multiple values proposal
I'm happy with your wording. There is one minor thing however:
(CALL-WITH-VALUES producer consumer) [Procedure]
Producer should be a procedure of zero arguments and consumer should be a
procedure. Consumer is applied to the value(s) returned by invoking
producer. CALL-WITH-VALUES returns the result(s) of the invocation of
consumer.
Producer does not have to be a procedure of exactly zero arguments.
There is no reason to outlaw procedures of zero or more arguments. On
the other hand, I don't feel at all strongly about this.
Perhaps "Producer should be a procedure that accepts zero arguments
and consumer should be a procedure..." would be better.
∂01-Sep-89 0544 ramsdell@linus.mitre.org Please rename BABY-DOE and agree on an agenda item
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Sep 89 05:44:31 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA02732; Fri, 1 Sep 89 08:33:10 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA21036; Fri, 1 Sep 89 08:34:06 EDT
Posted-Date: Fri, 01 Sep 89 08:27:22 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA05535; Fri, 1 Sep 89 08:27:23 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8909011227.AA05535@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Subject: Please rename BABY-DOE and agree on an agenda item
In-Reply-To: Your message of Thu, 31 Aug 89 15:10:00 -0700.
<8908312210.AA04962@spencer.cs.uoregon.edu>
Date: Fri, 01 Sep 89 08:27:22 EDT
>> From: will@cs.uoregon.edu
....
>> Summary of consensus: the VALUES procedure takes any number of arguments,
>> and simply passes them to its continuation. A procedure to be named
>> later takes a thunk and a procedure, and calls the thunk with a
>> continuation that, when passed some values, calls the procedure that
>> was the second argument to the procedure to be named later with those
>> values as arguments. Except for continuations created by the procedure
>> to be named later, all continuations take exactly one value, as now;
>> the effect of passing no value or more than one value to continuations
>> that were not created by the procedure to be named later is unspecified
>> (as indeed it is unspecified now).
This is an excellent summary of the consensus in my opinion.
>> You shouldn't have to worry so much about the wording, since that can
>> be left to whoever edits the R5RS.
Your wording of the consensus sounds like an excellent basis for a
wording of the proposal, however, I agree we should not worry about
the precise wording. Remember the R5RS editors most likely will
change whatever wording we generate. I would like to end up with some
agreed upon text that we can put on a meeting agenda. The text does
not have to be text for R5RS, but can be directions to the editor.
Let BABY-DOE be the name of the procedure which creates continuations
accepting multiple values. What do you think about this as a meeting
agenda item?
------------------------
The editors are directed to add text to R5RS so as to include the
procedures VALUES and BABY-DOE consistant with the following
definitions. The VALUES procedure takes any number of arguments, and
simply passes them to its continuation. The BABY-DOE procedure takes
a thunk and a procedure, and calls the thunk with a continuation that,
when passed some values, calls the procedure that was the second
argument to the BABY-DOE procedure with those values as arguments.
Except for continuations created by the BABY-DOE procedure, all
continuations take exactly one value, as now; the effect of passing no
value or more than one value to continuations that were not created by
the BABY-DOE procedure is unspecified (as indeed it is unspecified
now).
------------------------
I would like to separate the discussion on multiple values into the
two topics of naming BABY-DOE and agreeing upon the agenda item. I am
not against using actual R5RS text as the basis for an agenda item.
John
∂01-Sep-89 0610 ramsdell@linus.mitre.org Re: Multiple values not for R4RS
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Sep 89 06:10:08 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA02974; Fri, 1 Sep 89 08:54:42 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA21245; Fri, 1 Sep 89 08:55:21 EDT
Posted-Date: Fri, 01 Sep 89 08:48:37 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA05551; Fri, 1 Sep 89 08:48:39 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8909011248.AA05551@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Subject: Re: Multiple values not for R4RS
In-Reply-To: Your message of Thu, 31 Aug 89 13:17:44 -0700.
<8908312017.AA05748@Polya.Stanford.EDU>
Date: Fri, 01 Sep 89 08:48:37 EDT
>> From: Morris J. Katz <katz@Polya.Stanford.EDU>
...
>> If it is possible, I would be interested in what about my wording you
>> find troubling. (I realize that often bad feelings about wordings are
>> based on gut level feelings that are hard to explain.) Given some
>> input, I would be happy to work on refining my prose.
Sorry about that. I did not mean to be so gruff in my reply.
>> During the evaluation of a 'with-values' form, the 'generator' thunk
>> is first thawed (evaluated to yield some values) and then the 'receiver' is
>> applied to the values returned by 'generator'. This means that a
>> continuation captured in 'generator' includes the application of
>> 'receiver' to the values returned by 'generator'. It also includes the
>> return from 'with-values' of the value(s) returned by 'receiver'.
The problem I see with this text is that the continuation captured in
'generator' may not be the one your text suggests. Consider
(baby-doe
(lambda ()
(let ((x (call-with-current-continuation
(lambda (c) ...))))
....))
...)
One other point (a small nit I admit), is I prefer the phrase "the
'generator' is called to yield some values" to "the 'generator' is
first thawed (evaluated to yield some values)" but this is what
editors are for.
∂01-Sep-89 0623 ramsdell@linus.mitre.org Re: An alternate description of the multiple values proposal
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Sep 89 06:23:28 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA03116; Fri, 1 Sep 89 09:14:50 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA21412; Fri, 1 Sep 89 09:15:29 EDT
Posted-Date: Fri, 01 Sep 89 09:08:45 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA05558; Fri, 1 Sep 89 09:08:46 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8909011308.AA05558@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Subject: Re: An alternate description of the multiple values proposal
In-Reply-To: Your message of Thu, 31 Aug 89 12:51:32 -0700.
<890831-125133-8085@Xerox>
Date: Fri, 01 Sep 89 09:08:45 EDT
>> From: Pavel.pa@xerox.com
...
>> As I said in my last message on this topic, I'm pretty unsatisfied with the
>> descriptions that have been circulated thus far. Unfortunately, my
>> proposed description in that message seems to have been ignored, so I'll
>> repeat it here in the context of a complete proposed description of the
>> facility, including the write-ups of VALUES, CALL-WITH-VALUES, and
>> CALL-WITH-CURRENT-CONTINUATION.
Pavel, I thought I was responding to your concerns by changing my
description of VALUES so as not to special case the single-argument
case.
As to your current proposal, I think it has some strengths and
weaknesses. I like the terminology of producer/consumer better than
generator/receiver. The text describing
CALL-WITH-CURRENT-CONTINUATION also looks good. I think that the
BABY-DOE procedure should include text that makes it clear what
happens when the continuation given to the producer is captured by
CALL-WITH-CURRENT-CONTINUATION.
On naming BABY-DOE, I think we can assume that Pavel suggests
CALL-WITH-VALUES and Chris Hanson suggests WITH-VALUES.
John
∂01-Sep-89 0757 ramsdell@linus.mitre.org An alternative to ACCEPTS?
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Sep 89 07:57:11 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA03858; Fri, 1 Sep 89 10:47:42 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA22816; Fri, 1 Sep 89 10:48:42 EDT
Posted-Date: Fri, 01 Sep 89 10:41:58 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA05581; Fri, 1 Sep 89 10:41:59 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8909011441.AA05581@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Subject: An alternative to ACCEPTS?
In-Reply-To: Your message of Tue, 22 Aug 89 13:16:43 -0700.
<8908222017.AA22154@sde.hp.com>
Date: Fri, 01 Sep 89 10:41:58 EDT
[This is not part of the multiple values compromise.]
As an alternative to providing ACCEPTS?, maybe we should simply
provide a way of generating truncating continuations. Suppose we
provided a procedure like CALL-WITH-CURRENT-CONTINUATION, except that
if the escape procedure generated by CALL-WITH-CURRENT-CONTINUATION
accepts exactly n arguments, the new procedure generates an escape
procedure which will accept n or more arguments, and ignore the extra
ones. The advantage of this approach is that implementations are only
required to be able to compute the arity of escape procedures, not all
procedures. Here is an example of its use:
(define (quotient-and-maybe-remainder n1 n2)
(call-with-truncating-continuation
(lambda (k)
(let* ((q (quotient n1 n2))
(r (- n1 (* q n2))))
(k q r)))))
(quotient-and-maybe-remainder 1 1) => 1
John
∂01-Sep-89 0900 @mc.lcs.mit.edu,@life.ai.mit.edu:katz@polya.stanford.edu Programmer-defined data types, version 2
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Sep 89 09:00:17 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA04647; Fri, 1 Sep 89 11:50:28 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa16650;
1 Sep 89 11:44 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 1 Sep 89 11:44:47 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa16623;
1 Sep 89 11:42 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA04521; Fri, 1 Sep 89 11:42:53 EDT
Received: from Polya.Stanford.EDU (polya.stanford.edu) by zurich.ai.mit.edu; Fri, 1 Sep 89 11:39:35 edt
Received: by Polya.Stanford.EDU (5.61/25-eef) id AA04825; Fri, 1 Sep 89 08:42:07 -0700
Date: Fri, 1 Sep 89 08:42:07 -0700
From: "Morris J. Katz" <katz@polya.stanford.edu>
Message-Id: <8909011542.AA04825@Polya.Stanford.EDU>
To: cph@zurich.ai.mit.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Chris Hanson's message of Thu, 31 Aug 89 18:15:50 edt <8908312215.AA07597@zurich.ai.mit.edu>
Subject: Programmer-defined data types, version 2
Date: Thu, 31 Aug 89 18:15:50 edt
From: cph@zurich.ai.mit.edu (Chris Hanson)
Date: Thu, 31 Aug 89 13:26:10 -0700
From: Morris J. Katz <katz@Polya.Stanford.EDU>
Date: Thu, 31 Aug 89 14:42:33 edt
From: cph@zurich.ai.mit.edu (Chris Hanson)
Date: Wed, 30 Aug 89 12:02:13 -0700
From: "Morris J. Katz" <katz@polya.stanford.edu>
For aesthetic reasons I would prefer to see
(MAKE-RECORD-TYPE type-name . field-names)
rather than
(MAKE-RECORD-TYPE type-name field-names)
as the for for MAKE-RECORD-TYPE.
How do others feel?
I prefer having a single argument which is a list. Not only does this
reduce the number of characters that must be typed, but it simplifies
abstraction on the `field-names' argument, and leaves the argument
list open for adding arguments in the future.
I might be swayed that it is important to leave the rest argument
position open for future extensions; but, I hardly buy that the
trade-off between 3 characters to form the list and one character per
symbol to make it into a symbol represents enough of a difference in
keystrokes to be important. (My approach is actually shorter for
records of 1 or 2 fields (-:)
Since I was obviously making an aesthetic argument, let's just
summarize by saying I prefer the aesthetics of a single list argument.
(I notice that you said nothing about my "abstraction" argument.)
Maybe I am just being dense, but I am not sure to what you are
refering in your abstraction argument. It is for that reason that I
did not respond to it.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂01-Sep-89 0909 katz@polya.stanford.edu Multiple values not for R4RS
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Sep 89 09:09:16 PDT
Received: from Polya.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA04753; Fri, 1 Sep 89 11:57:37 EDT
Received: by Polya.Stanford.EDU (5.61/25-eef) id AA05427; Fri, 1 Sep 89 08:56:44 -0700
Date: Fri, 1 Sep 89 08:56:44 -0700
From: Morris J. Katz <katz@polya.stanford.edu>
Message-Id: <8909011556.AA05427@Polya.Stanford.EDU>
To: ramsdell@linus.mitre.org
Cc: rrrs-authors@life.ai.mit.edu
In-Reply-To: ramsdell@linus.mitre.org's message of Fri, 01 Sep 89 08:48:37 EDT <8909011248.AA05551@huxley.mitre.org>
Subject: Multiple values not for R4RS
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Posted-Date: Fri, 01 Sep 89 08:48:37 EDT
From: ramsdell@linus.mitre.org
Date: Fri, 01 Sep 89 08:48:37 EDT
>> From: Morris J. Katz <katz@Polya.Stanford.EDU>
...
>> During the evaluation of a 'with-values' form, the 'generator' thunk
>> is first thawed (evaluated to yield some values) and then the 'receiver' is
>> applied to the values returned by 'generator'. This means that a
>> continuation captured in 'generator' includes the application of
>> 'receiver' to the values returned by 'generator'. It also includes the
>> return from 'with-values' of the value(s) returned by 'receiver'.
The problem I see with this text is that the continuation captured in
'generator' may not be the one your text suggests. Consider
(baby-doe
(lambda ()
(let ((x (call-with-current-continuation
(lambda (c) ...))))
....))
...)
We can leave it to the editors (since that seems to be the current
sentiment), but I believe that my wording is actually correct relative
to your example. The continuation which is captured does include the
application of 'receiver' to the values returned by 'generator', just
possibly not as the first action to be taken by the continuation. I
tried to be fairly careful in my wording precisely because of the
example you have given.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂01-Sep-89 0914 katz@polya.stanford.edu An alternative to ACCEPTS?
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Sep 89 09:14:00 PDT
Received: from Polya.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA04805; Fri, 1 Sep 89 12:02:25 EDT
Received: by Polya.Stanford.EDU (5.61/25-eef) id AA05706; Fri, 1 Sep 89 09:01:37 -0700
Date: Fri, 1 Sep 89 09:01:37 -0700
From: Morris J. Katz <katz@polya.stanford.edu>
Message-Id: <8909011601.AA05706@Polya.Stanford.EDU>
To: ramsdell@linus.mitre.org
Cc: rrrs-authors@life.ai.mit.edu
In-Reply-To: ramsdell@linus.mitre.org's message of Fri, 01 Sep 89 10:41:58 EDT <8909011441.AA05581@huxley.mitre.org>
Subject: An alternative to ACCEPTS?
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Posted-Date: Fri, 01 Sep 89 10:41:58 EDT
From: ramsdell@linus.mitre.org
Date: Fri, 01 Sep 89 10:41:58 EDT
[This is not part of the multiple values compromise.]
As an alternative to providing ACCEPTS?, maybe we should simply
provide a way of generating truncating continuations. Suppose we
provided a procedure like CALL-WITH-CURRENT-CONTINUATION, except that
if the escape procedure generated by CALL-WITH-CURRENT-CONTINUATION
accepts exactly n arguments, the new procedure generates an escape
procedure which will accept n or more arguments, and ignore the extra
ones. The advantage of this approach is that implementations are only
required to be able to compute the arity of escape procedures, not all
procedures. Here is an example of its use:
(define (quotient-and-maybe-remainder n1 n2)
(call-with-truncating-continuation
(lambda (k)
(let* ((q (quotient n1 n2))
(r (- n1 (* q n2))))
(k q r)))))
(quotient-and-maybe-remainder 1 1) => 1
John
I would be unhappy with a special mechanism that handles only half of
the interesting cases. It virtually guarantees that no mechanism
which handles the entire problem will be adopted in the foreseeable
future. This is particularly true in this case in which their is no
natural extension of the special purpose mechanism to a more general one.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂01-Sep-89 0949 ramsdell@linus.mitre.org Re: Multiple values not for R4RS
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Sep 89 09:49:21 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA05179; Fri, 1 Sep 89 12:39:59 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA24183; Fri, 1 Sep 89 12:40:28 EDT
Posted-Date: Fri, 01 Sep 89 12:33:42 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA05694; Fri, 1 Sep 89 12:33:44 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8909011633.AA05694@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Subject: Re: Multiple values not for R4RS
In-Reply-To: Your message of Fri, 01 Sep 89 08:56:44 -0700.
<8909011556.AA05427@Polya.Stanford.EDU>
Date: Fri, 01 Sep 89 12:33:42 EDT
>> From: Morris J. Katz <katz@Polya.Stanford.EDU>
...
>> We can leave it to the editors (since that seems to be the current
>> sentiment) ....
Leave it to the editors if you want to, not because it seems to be the
current sentiment. You count!
I understand your text now. I guess I find the term "includes"
ambiguous. Let me suggest another approach to explaining BABY-DOE.
I follow the lead of Will and the semantics.
The BABY-DOE procedure takes a thunk and a procedure, and calls the
thunk with a continuation that, when passed some values, calls the
procedure that was the second argument to the BABY-DOE procedure with
those values as arguments. The result of a call of the BABY-DOE
procedure is the result of the call of the second argument.
John
∂01-Sep-89 1050 Pavel.pa@xerox.com Re: An alternate description of the multiple values proposal
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Sep 89 10:50:19 PDT
Received: from Xerox.COM by life.ai.mit.edu (4.1/AI-4.10) id AA05737; Fri, 1 Sep 89 13:40:41 EDT
Received: from Cabernet.ms by ArpaGateway.ms ; 01 SEP 89 10:40:23 PDT
Date: Fri, 01 Sep 89 10:40:57 PDT
From: Pavel.pa@xerox.com
Subject: Re: An alternate description of the multiple values proposal
In-Reply-To: <8909011308.AA05558@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Message-Id: <890901-104023-1225@Xerox>
I have a disagreement with Will's description of the consensus. He says,
``Except for continuations created by the procedure to be named later, all
continuations take exactly one value, as now''. I firmly believe that
continuations for the ``for effect'' context should take any number of
arguments; I would very much not like to see this left unspecified.
I agree with Jinx's correction to my description of CALL-WITH-VALUES
(stating that the producer accepts zero arguments instead of insisting that
it be a procedure of exactly zero arguments).
John, I appreciate that you were responding to my concerns when you removed
the special-casing from the description of VALUES, but that was not the
greatest of my concerns. My major issues concern some added degree of
precision in the description and also a statement about the arity of ``for
effect'' continuations. That's why I felt the need to propose a different
description. Let me respond to your comments on that decription.
You say, ``I think that the BABY-DOE procedure should include text that
makes it clear what happens when the continuation given to the producer is
captured by CALL-WITH-CURRENT-CONTINUATION.''
I thought the combination of the statements ``Consumer is applied to the
value(s) returned by invoking producer. CALL-WITH-VALUES returns the
result(s) of the invocation of consumer.'' and the discussion of the sixth
context in the description of CALL-WITH-CURRENT-CONTINUATION made it clear
what happens. If not, could you suggest a sentence or two that improves
the situation?
On the subject of naming BABY-DOE, consider the only procedures in R3.95RS
whose names begin with ``WITH-'':
WITH-INPUT-FROM-FILE
WITH-OUTPUT-TO-FILE
Both of these have an effect with dynamic extent, and the ``body''
procedure in each case is a thunk. Thus, the effect of these procedures is
to do some magic that lets the bodies behave differently than they would
without the procedure.
On the other hand, the procedures with ``CALL-WITH-'' in their names are as
follows:
CALL-WITH-CURRENT-CONTINUATION
CALL-WITH-INPUT-FILE
CALL-WITH-OUTPUT-FILE
These all take a ``body'' procedure and zero or one other arguments. A
computation is done on the other arguments and the result is passed as an
argument to the body procedure. No dynamic extent magic is involved and
the context of the body is no different than what it would be if it were
not an argument to one of these procedures.
I think that the resemblence of BABY-DOE to the latter set of procedures is
quite strong and that the resemblence to the former set is quite weak if it
exists at all. Thus, on the grounds of consistency in naming, I support
CALL-WITH-VALUES.
Pavel
∂01-Sep-89 1404 cph@zurich.ai.mit.edu An alternate description of the multiple values proposal
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Sep 89 14:04:33 PDT
Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA07990; Fri, 1 Sep 89 16:35:01 EDT
Received: from localhost by zurich.ai.mit.edu; Fri, 1 Sep 89 16:31:46 edt
Date: Fri, 1 Sep 89 16:31:46 edt
From: cph@zurich.ai.mit.edu (Chris Hanson)
Message-Id: <8909012031.AA10876@zurich.ai.mit.edu>
To: ramsdell@linus.mitre.org
Cc: rrrs-authors@life.ai.mit.edu
In-Reply-To: ramsdell@linus.mitre.org's message of Fri, 01 Sep 89 09:08:45 EDT <8909011308.AA05558@huxley.mitre.org>
Subject: An alternate description of the multiple values proposal
From: ramsdell@linus.mitre.org
Date: Fri, 01 Sep 89 09:08:45 EDT
On naming BABY-DOE, I think we can assume that Pavel suggests
CALL-WITH-VALUES and Chris Hanson suggests WITH-VALUES.
I've changed my mind. I now agree with Pavel and prefer
`call-with-values'.
∂01-Sep-89 1419 cph@zurich.ai.mit.edu An alternate description of the multiple values proposal
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Sep 89 14:19:10 PDT
Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA08316; Fri, 1 Sep 89 16:58:11 EDT
Received: from localhost by zurich.ai.mit.edu; Fri, 1 Sep 89 16:55:00 edt
Date: Fri, 1 Sep 89 16:55:00 edt
From: cph@zurich.ai.mit.edu (Chris Hanson)
Message-Id: <8909012055.AA10886@zurich.ai.mit.edu>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@life.ai.mit.edu
In-Reply-To: Pavel.pa@xerox.com's message of Fri, 01 Sep 89 10:40:57 PDT <890901-104023-1225@Xerox>
Subject: An alternate description of the multiple values proposal
Date: Fri, 01 Sep 89 10:40:57 PDT
From: Pavel.pa@xerox.com
I have a disagreement with Will's description of the consensus. He says,
``Except for continuations created by the procedure to be named later, all
continuations take exactly one value, as now''. I firmly believe that
continuations for the ``for effect'' context should take any number of
arguments; I would very much not like to see this left unspecified.
I'm not sure I agree with this definition of "for effect"
continuations. I do agree that they should be required to accept
either zero arguments (because that is the "correct" arity for a
strict semantics) or one argument (for compatibility with existing
code). However, I see no compelling reason why such continuations
should be required to accept more than one argument. I would prefer
to leave this unspecified, because I believe it is an exact parallel
with the case of "for value" implicit continuations accepting more
than one argument.
(I can imagine that if I were considering the design of a new
language, I might choose a strict semantics in which "for effect"
implicit continuations accepted -only- zero arguments, and "for value"
implicit continuations accepted -only- one argument. There is a
simple elegance in such a design that I find appealing.)
∂01-Sep-89 1505 Pavel.pa@xerox.com Re: An alternate description of the multiple values proposal
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Sep 89 15:05:05 PDT
Received: from Xerox.COM by life.ai.mit.edu (4.1/AI-4.10) id AA09028; Fri, 1 Sep 89 17:53:34 EDT
Received: from Cabernet.ms by ArpaGateway.ms ; 01 SEP 89 14:49:31 PDT
Date: Fri, 01 Sep 89 14:50:23 PDT
From: Pavel.pa@xerox.com
Subject: Re: An alternate description of the multiple values proposal
In-Reply-To: <8909012055.AA10886@zurich.ai.mit.edu>
To: rrrs-authors@life.ai.mit.edu
Message-Id: <890901-144931-1853@Xerox>
Date: Fri, 1 Sep 89 16:55:00 edt
From: cph@zurich.ai.mit.edu (Chris Hanson)
I'm not sure I agree with this definition of "for effect"
continuations. I do agree that they should be required to accept
either zero arguments (because that is the "correct" arity for a
strict semantics) or one argument (for compatibility with existing
code). However, I see no compelling reason why such continuations
should be required to accept more than one argument. I would prefer
to leave this unspecified, because I believe it is an exact parallel
with the case of "for value" implicit continuations accepting more
than one argument.
After sending my note, I took a look at the current (R3.95RS) semantics.
It shows a continuation for ``commands'' (that is, expressions in
``effect'' context) that takes any sequence of values and ignores all of
them. Of course, the formal semantics has no weight, but I found it
interesting.
I think that I have always been bothered by languages (like Pascal and
Mesa) that require me to ``do'' something with the returned values of
procedures. It always seems to me that I already explained what to do with
them: ignore them. Thus, I don't quite agree with the feeling that zero
values is somehow the ``correct'' number for expressions in effect context.
I can, however, appreciate something of the general gestalt that gives you
that feeling.
I think that my major reason for wanting effect continuations to accept
many values is for consistency with single-value-returning expressions; I
don't see a compelling reason to distinguish the two unnecessarily. It
would seem weird to me if single-valued expressions somehow got preference
over multiple-valued ones in such a case, in which there appears no
semantic justification.
Pavel
∂01-Sep-89 1507 jinx@zurich.ai.mit.edu An alternate description of the multiple values proposal
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Sep 89 15:07:08 PDT
Received: from zurich.ai.mit.edu ([18.43.0.171]) by life.ai.mit.edu (4.1/AI-4.10) id AA09113; Fri, 1 Sep 89 18:01:10 EDT
Received: from localhost by zurich.ai.mit.edu; Fri, 1 Sep 89 17:57:54 edt
Date: Fri, 1 Sep 89 17:57:54 edt
From: jinx@zurich.ai.mit.edu (Guillermo J. Rozas)
Message-Id: <8909012157.AA14800@zurich.ai.mit.edu>
To: cph@zurich.ai.mit.edu
Cc: Pavel.pa@xerox.com, rrrs-authors@life.ai.mit.edu
In-Reply-To: Chris Hanson's message of Fri, 1 Sep 89 16:55:00 edt <8909012055.AA10886@zurich.ai.mit.edu>
Subject: An alternate description of the multiple values proposal
(I can imagine that if I were considering the design of a new
language, I might choose a strict semantics in which "for effect"
implicit continuations accepted -only- zero arguments, and "for value"
implicit continuations accepted -only- one argument. There is a
simple elegance in such a design that I find appealing.)
There are a few problems with requiring "effect" continuations to expect
exactly zero values:
- Backwards compatibility (obviously not a problem with a new
language).
- Is the continuation for the call to FOO an effect continuation or
not?
(let ((ignored (foo <some args>)))
<some code that does not use ignored>)
- If it is not, then BEGIN is more primitive than I would like to see
it, since the "traditional" expansion as
(begin <exp1> <more>) ->
(let ((ignored1 <exp1>)
(next1 (lambda () (begin <more>))))
(next1))
no longer works because the arity of the continuation will be wrong.
- If it is an effect continuation, we have a problem, since in general
we can't decide statically whether a return value will be used or
not, and thus we can't decide in general whether a continuation is
for effect or not.
∂01-Sep-89 1516 cph@zurich.ai.mit.edu An alternate description of the multiple values proposal
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Sep 89 15:16:11 PDT
Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA09234; Fri, 1 Sep 89 18:07:18 EDT
Received: from localhost by zurich.ai.mit.edu; Fri, 1 Sep 89 18:04:02 edt
Date: Fri, 1 Sep 89 18:04:02 edt
From: cph@zurich.ai.mit.edu (Chris Hanson)
Message-Id: <8909012204.AA14425@zurich.ai.mit.edu>
To: jinx@zurich.ai.mit.edu
Cc: Pavel.pa@xerox.com, rrrs-authors@life.ai.mit.edu
In-Reply-To: Guillermo J. Rozas's message of Fri, 1 Sep 89 17:57:54 edt
Subject: An alternate description of the multiple values proposal
Date: Fri, 1 Sep 89 17:57:54 edt
From: jinx (Guillermo J. Rozas)
(I can imagine that if I were considering the design of a new
language, I might choose a strict semantics in which "for effect"
implicit continuations accepted -only- zero arguments, and "for value"
implicit continuations accepted -only- one argument. There is a
simple elegance in such a design that I find appealing.)
There are a few problems with requiring "effect" continuations to expect
exactly zero values:
- Is the continuation for the call to FOO an effect continuation or
not?
(let ((ignored (foo <some args>)))
<some code that does not use ignored>)
- If it is not, then BEGIN is more primitive than I would like to see
it, since the "traditional" expansion as
(begin <exp1> <more>) ->
(let ((ignored1 <exp1>)
(next1 (lambda () (begin <more>))))
(next1))
no longer works because the arity of the continuation will be wrong.
The continuation for this call is -not- an "effect" continuation. I
don't see this as a problem -- it merely means that the expansion for
`begin' must be described in terms of `call-with-values':
(begin <action> <more>) ->
(call-with-values (lambda () <action>) (lambda () (begin <more>)))
I don't see this as being appreciably different. I also don't see any
problem with "primitiveness" since `call-with-values' must be
implemented as a primitive in any case.
∂01-Sep-89 1635 Pavel.pa@xerox.com Re: An alternate description of the multiple values proposal
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Sep 89 16:35:35 PDT
Received: from Xerox.COM by life.ai.mit.edu (4.1/AI-4.10) id AA09710; Fri, 1 Sep 89 18:47:06 EDT
Received: from Cabernet.ms by ArpaGateway.ms ; 01 SEP 89 15:41:54 PDT
Date: Fri, 01 Sep 89 15:42:50 PDT
From: Pavel.pa@xerox.com
Subject: Re: An alternate description of the multiple values proposal
In-Reply-To: <8909012204.AA14425@zurich.ai.mit.edu>
To: rrrs-authors@life.ai.mit.edu
Message-Id: <890901-154154-1998@Xerox>
I also don't see the call in Jinx's example as being in effect context. I
think Chris is right about defining BEGIN in terms of CALL-WITH-VALUES. Of
course, Chris and I disagree about the argument list of the consumer:
(begin <action> <more>) ->
(call-with-values (lambda () <action>)
(lambda ignored (begin <more>)))
It is interesting to note that the formal semantics gives a very different
translation of BEGIN:
(begin <sequence>) -> ((lambda () <sequence>))
∂01-Sep-89 1653 @mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu Programmer-defined data types, version 2
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Sep 89 16:53:10 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA09912; Fri, 1 Sep 89 18:59:26 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa20407;
1 Sep 89 16:46 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 1 Sep 89 16:46:19 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa20337;
1 Sep 89 16:41 EDT
Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA08073; Fri, 1 Sep 89 16:41:49 EDT
Received: from localhost by zurich.ai.mit.edu; Fri, 1 Sep 89 16:38:38 edt
Date: Fri, 1 Sep 89 16:38:38 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
Message-Id: <8909012038.AA10881@zurich.ai.mit.edu>
To: katz@polya.stanford.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Morris J. Katz's message of Fri, 1 Sep 89 08:42:07 -0700 <8909011542.AA04825@Polya.Stanford.EDU>
Subject: Programmer-defined data types, version 2
Date: Fri, 1 Sep 89 08:42:07 -0700
From: Morris J. Katz <katz@Polya.Stanford.EDU>
Date: Thu, 31 Aug 89 18:15:50 edt
From: cph@zurich.ai.mit.edu (Chris Hanson)
Date: Thu, 31 Aug 89 13:26:10 -0700
From: Morris J. Katz <katz@Polya.Stanford.EDU>
I might be swayed that it is important to leave the rest argument
position open for future extensions; but, I hardly buy that the
trade-off between 3 characters to form the list and one character per
symbol to make it into a symbol represents enough of a difference in
keystrokes to be important. (My approach is actually shorter for
records of 1 or 2 fields (-:)
Since I was obviously making an aesthetic argument, let's just
summarize by saying I prefer the aesthetics of a single list argument.
(I notice that you said nothing about my "abstraction" argument.)
Maybe I am just being dense, but I am not sure to what you are
refering in your abstraction argument. It is for that reason that I
did not respond to it.
What I mean by being able to "abstract" on that argument is that its
value can by computed as an arbitrary expression. I can easily
imagine circumstances where this is desirable.
On the other hand, I could do this with a rest argument by means of
`apply'; but I find that alternative clumsy and unattractive.
Furthermore, it feels like a kludge to compensate for the fact that
the "field list" no longer has any distinct identity.
∂01-Sep-89 1857 @mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com Programmer-defined data types, last (?) version
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Sep 89 18:57:05 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA09987; Fri, 1 Sep 89 19:09:40 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa20657;
1 Sep 89 17:07 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 1 Sep 89 17:07:39 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa20599;
1 Sep 89 17:04 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA08408; Fri, 1 Sep 89 17:04:33 EDT
Received: from Xerox.COM (xerox.com) by zurich.ai.mit.edu; Fri, 1 Sep 89 17:01:04 edt
Received: from Cabernet.ms by ArpaGateway.ms ; 01 SEP 89 13:49:26 PDT
Date: Fri, 01 Sep 89 13:50:16 PDT
From: Pavel.pa@xerox.com
Subject: Programmer-defined data types, last (?) version
To: RRRS-Authors@zurich.ai.mit.edu
Cc: Pavel.pa@xerox.com
Message-Id: <890901-134926-1681@Xerox>
Morry Katz suggested that the field-names argument to MAKE-RECORD-TYPE be
spread out, as the 2nd through nth arguments. I agree with Chris Hanson in
his opposition to this, primarily because I want to be able to extend this
functionality with extra, optional arguments to MAKE-RECORD-TYPE (e.g., in
Cedar Scheme, an optional parent rtd and printing procedure can be given).
In private mail, Alan Bawden asked for a more explicit statement concerning
the order of arguments to record updaters (it is as in SET-CAR!, with the
record to be changed followed by the new value for the field). I have done
this below.
Alan also asked for more information about the result of applying RECORD?
to various types of values, such as pairs, promises, numbers, etc. I have
updated its description to say that RECORD? may return true for any Scheme
value; of course, if it does so, then RECORD-TYPE-DESCRIPTOR will also be
applicable to that value and will return an ``appropriate'' record-type
descriptor. I also added a note to the effect that the type of descriptors
is not necessarily disjoint from the other types in Scheme.
Jonathan Rees points out that, given the optionality of the second argument
to RECORD-CONSTRUCTOR, it is gratuitous to have RECORD-TYPE-FIELD-NAMES
return some random permutation of the original list. I agree and have
changed the description back to its previous form, specifying that the
resulting list is EQUAL? to the one given when the type was created.
Here is the third and, I dare to hope, final version of the proposal.
Will, does this look like consensus?
Pavel
=====================
We propose adding the following procedures to Scheme:
(MAKE-RECORD-TYPE type-name field-names)
Returns a ``record-type descriptor'', a value representing a new data type,
disjoint from all others. The type-name argument must be a string, but is
only used for debugging purposes (such as the printed representation of a
record of the new type). The field-names argument is a list of symbols
naming the ``fields'' of a record of the new type. It is an error if the
list contains any duplicates. It is unspecified how record-type
descriptors are represented.
(RECORD-CONSTRUCTOR rtd [field-names])
Returns a procedure for constructing new members of the type represented by
rtd. The returned procedure accepts exactly as many arguments as there are
symbols in the given list, field-names; these are used, in order, as the
initial values of those fields in a new record, which is returned by the
constructor procedure. The values of any fields not named in that list are
unspecified. The field-names argument defaults to the list of field-names
in the call to MAKE-RECORD-TYPE that created the type represented by rtd;
if the field-names argument is provided, it is an error if it contains any
duplicates or any symbols not in the default list.
(RECORD-PREDICATE rtd)
Returns a procedure for testing membership in the type represented by rtd.
The returned procedure accepts exactly one argument and returns a true
value if the argument is a member of the indicated record type; it returns
a false value otherwise.
(RECORD-ACCESSOR rtd field-name)
Returns a procedure for reading the value of a particular field of a member
of the type represented by rtd. The returned procedure accepts exactly one
argument which must be a record of the appropriate type; it returns the
current value of the field named by the symbol field-name in that record.
The symbol field-name must be a member of the list of field-names in the
call to MAKE-RECORD-TYPE that created the type represented by rtd.
(RECORD-UPDATER rtd field-name)
Returns a procedure for writing the value of a particular field of a member
of the type represented by rtd. The returned procedure accepts exactly two
arguments: first, a record of the appropriate type, and second, an
arbitrary Scheme value; it modifies the field named by the symbol
field-name in that record to contain the given value. The returned value
of the updater procedure is unspecified. The symbol field-name must be a
member of the list of field-names in the call to MAKE-RECORD-TYPE that
created the type represented by rtd.
(RECORD? obj)
Returns a true value if obj is a record of any type and a false value
otherwise. Note that RECORD? may be true of any Scheme value; of course,
if it returns true for some particular value, then RECORD-TYPE-DESCRIPTOR
is applicable to that value and returns an appropriate descriptor.
(RECORD-TYPE-DESCRIPTOR record)
Returns a record-type descriptor representing the type of the given record.
That is, for example, if the returned descriptor were passed to
RECORD-PREDICATE, the resulting predicate would return a true value when
passed the given record. Note that it is not necessarily the case that the
returned descriptor is the one that was passed to RECORD-CONSTRUCTOR in the
call that created the constructor procedure that created the given record.
(RECORD-TYPE-NAME rtd)
Returns the type-name associated with the type represented by rtd. The
returned value is EQV? to the type-name argument given in the call to
MAKE-RECORD-TYPE that created the type represented by rtd.
(RECORD-TYPE-FIELD-NAMES rtd)
Returns a list of the symbols naming the fields in members of the type
represented by rtd. The returned value is EQUAL? to the field-names
argument given in the call to MAKE-RECORD-TYPE that created the type
represented by rtd.
=====================
Notes on the proposal
=====================
-- The procedure RECORD? is necessary to allow reliable use of the
procedure RECORD-TYPE-DESCRIPTOR.
-- The type-name argument to MAKE-RECORD-TYPE is constrained to be a string
in order to allow experimentation with interesting semantics for other
kinds of values there. One possibility raised in the discussion in May and
June of 1988 was some kind of a ``handler'' procedure, as in T objects.
-- We do not propose any general macro for the definition of record types.
The feeling is that this is not easy to do in a way that is both elegant
and sufficiently flexible. Once we have macros, the primitives above
should be sufficient for portable experimentation.
-- The issues of subtyping and inheritance, print methods, and integration
with modules and/or
environments (e.g., Pascal's WITH construct) have been purposely avoided in
order to achieve more rapid consensus. Designs for adding single
inheritance appeared in the discussion in 1988.
-- EQ? and EQV? treat records in the same way as they do pairs, vectors,
and strings. EQUAL? is equivalent to EQV? on records.
∂05-Sep-89 0916 ramsdell@linus.mitre.org Name for BABY-DOE should not include "values".
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 5 Sep 89 09:16:05 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA04716; Tue, 5 Sep 89 11:54:56 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA19127; Tue, 5 Sep 89 08:59:53 EDT
Posted-Date: Tue, 05 Sep 89 08:53:08 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA09039; Tue, 5 Sep 89 08:53:09 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8909051253.AA09039@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Cc: ramsdell@linus.mitre.org
Subject: Name for BABY-DOE should not include "values".
In-Reply-To: Your message of Fri, 01 Sep 89 16:31:46 -0400.
<8909012031.AA10876@zurich.ai.mit.edu>
Date: Tue, 05 Sep 89 08:53:08 EDT
I prefer a name for BABY-DOE which does not include the word "values".
The reason is that I believe such names are misleading. In my
opinion, BABY-DOE gives me a way of creating an unusual continuation
to be used during a call of a thunk. It is unusual because it splices
in a call of a procedure into the current continuation. The important
fact about BABY-DOE is not that it calls a procedure with some values.
Please verify my point by studying the formal semantics.
Unfortunately, I have not yet come up with a good alternative name.
Here are some of my current tries:
CALL-PREFIXING-CONTINUATION
CALL-SPLICING-CONTINUATION
CALL-FORWARDING
CONNECT
LINK
CPS-CALL for "Continuation Passing Style CALL"
John
∂05-Sep-89 0918 ramsdell@linus.mitre.org Re: An alternate description of the multiple values proposal
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 5 Sep 89 09:18:33 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA04875; Tue, 5 Sep 89 12:06:57 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA19941; Tue, 5 Sep 89 09:45:21 EDT
Posted-Date: Tue, 05 Sep 89 09:38:35 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA09068; Tue, 5 Sep 89 09:38:36 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8909051338.AA09068@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Cc: ramsdell@linus.mitre.org
Subject: Re: An alternate description of the multiple values proposal
In-Reply-To: Your message of Fri, 01 Sep 89 15:42:50 -0700.
<890901-154154-1998@Xerox>
Date: Tue, 05 Sep 89 09:38:35 EDT
So do people agree with Will's statement that we should not worry
about the wording of a multiple values proposal? I am quite willing
to trust the editors. I assume we will agree, so, I will refrain from
making editorial comments.
>> From: Pavel.pa@xerox.com
...
>> I have a disagreement with Will's description of the consensus. He says,
>> ``Except for continuations created by the procedure to be named later, all
>> continuations take exactly one value, as now''. I firmly believe that
>> continuations for the ``for effect'' context should take any number of
>> arguments; I would very much not like to see this left unspecified.
...
It seems to me that Will's description of the consensus is a good one
in the sense that it represents the minimum change required to get
usable multiple values into Scheme. It represents a compromise I
suspect all will embrace. I hope Pavel agrees it is better than
nothing.
I suggest that the arity of `for effect' continuations be left as the
subject of a separate agenda item. Simply put, I do not want to risk
the multiple values compromise on this point. Remember, the consensus
on multiple values is not supposed to be the last word on the subject.
I expect further proposals on procedures related to ACCEPT? for
example.
John
∂05-Sep-89 1446 @mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@relay.cs.net:jmiller@cs.brandeis.edu Programmer-defined data types, last (?) version
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 5 Sep 89 14:45:54 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA08791; Tue, 5 Sep 89 17:31:31 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa10878;
5 Sep 89 17:26 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 5 Sep 89 17:26:48 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa10766;
5 Sep 89 17:20 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA08614; Tue, 5 Sep 89 17:20:08 EDT
Received: from RELAY.CS.NET (relay.cs.net) by zurich.ai.mit.edu; Tue, 5 Sep 89 17:16:51 edt
Message-Id: <8909052116.AA28244@zurich.ai.mit.edu>
Received: from relay2.cs.net by RELAY.CS.NET id ab20537; 5 Sep 89 16:11 EDT
Received: from cs.brandeis.edu by RELAY.CS.NET id ad03696; 5 Sep 89 17:09 EDT
Received: by cs.brandeis.edu (14.2/6.0.GT)
id AA19086; Tue, 5 Sep 89 07:27:19 edt
Date: Tue, 5 Sep 89 07:27:19 edt
From: Jim Miller <jmiller%cs.brandeis.edu@relay.cs.net>
Posted-Date: Tue, 5 Sep 89 07:27:19 edt
To: Pavel.pa.2@cs.brandeis.edu
Cc: RRRS-Authors.2@cs.brandeis.edu, Pavel.pa.2@cs.brandeis.edu
In-Reply-To: Pavel.pa@xerox.com's message of Fri, 01 Sep 89 13:50:16 PDT <890901-134926-1681@Xerox>
Subject: Programmer-defined data types, last (?) version
Reply-To: JMiller%cs.Brandeis.edu@relay.cs.net
Sorry, but I was waiting for something close to consensus to emerge
before sending in my one picky comment about the proposal. I don't
like the fact that the type name is a string, and the rationale makes
no sense to me whatsoever. As I understand it, you want to force the
T experiments to be non-portable EVEN IF the user never uses the
properties of the object that are the type's name? Why not leave the
position entirely unrestricted, since it has only one property of
interest: given a record you can retrieve this value. Surely, even
the most exotic experiments are unlikely to depend on the fact that
this object can't be retrieved once it is used to create a record
constructor?
--Jim
∂05-Sep-89 2222 Pavel.pa@xerox.com Re: Name for BABY-DOE should not include "values".
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 5 Sep 89 22:22:30 PDT
Received: from Xerox.COM by life.ai.mit.edu (4.1/AI-4.10) id AA12651; Wed, 6 Sep 89 00:10:00 EDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 SEP 89 15:08:31 PDT
Date: Tue, 05 Sep 89 15:14:16 PDT
From: Pavel.pa@xerox.com
Subject: Re: Name for BABY-DOE should not include "values".
In-Reply-To: <8909051253.AA09039@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Message-Id: <890905-150831-2109@Xerox>
John says, ``The important fact about BABY-DOE is not that it calls a
procedure with some values. Please verify my point by studying the formal
semantics.''
I disagree completely; to my mind, that is the entire significance of
BABY-DOE. I don't see that there is anything ``unusual'' about the
continuation created by BABY-DOE. It is just one of several kinds of
continuations, each with very different behavior, created by IF, SET!,
function-application, etc. In short, I don't think it needs a name
referring to continuations any more than IF or SET! does. Of course, it is
an operation on continuations, but most things are.
None of John's current tries at a better name seems even close to having
the perspicacity of ``call-with-values''.
Pavel
∂05-Sep-89 2349 @mc.lcs.mit.edu,@life.ai.mit.edu:bawden@arisia.xerox.com Programmer-defined data types, last (?) version
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 5 Sep 89 23:49:04 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA13349; Wed, 6 Sep 89 02:26:57 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa13781;
5 Sep 89 22:08 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 5 Sep 89 22:08:19 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa13769;
5 Sep 89 22:06 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA11092; Tue, 5 Sep 89 22:05:51 EDT
Received: from arisia.Xerox.COM (arisia.xerox.com) by zurich.ai.mit.edu; Tue, 5 Sep 89 22:02:36 edt
Received: from roo.parc.Xerox.COM by arisia.Xerox.COM with SMTP
(5.61+/IDA-1.2.8/gandalf) id AA23168; Tue, 5 Sep 89 19:02:01 -0700
Received: from mr-bun.parc.Xerox.COM by roo.parc.xerox.com with SMTP
(5.61+/IDA-1.2.8/gandalf) id AA03460; Tue, 5 Sep 89 19:05:03 PDT
Date: Tue, 5 Sep 89 19:03 PDT
From: Alan Bawden <bawden@parc.xerox.com>
Subject: Programmer-defined data types, last (?) version
To: JMiller%cs.Brandeis.edu@relay.cs.net
Cc: Pavel.pa@xerox.com, RRRS-Authors@zurich.ai.mit.edu
In-Reply-To: <8909052116.AA28244@zurich.ai.mit.edu>
Message-Id: <19890906020319.1.ALAN@MR-BUN.parc.xerox.com>
Date: Tue, 5 Sep 89 07:27:19 edt
From: Jim Miller <jmiller%cs.brandeis.edu@relay.cs.net>
... I don't like the fact that the type name is a string, and the
rationale makes no sense to me whatsoever.... Why not leave the
position entirely unrestricted, since it has only one property of
interest: given a record you can retrieve this value.
Perhaps I want to write a portable browser. I want to be able to display
things like:
The object #<RECORD 343241> is a Spaceship. It's fields are:
CAPTAIN: #<RECORD 442425>
X-POS: 3142.776
Y-POS: 0.0
If an implementation is free to re-use that argument, assigning it a role
other than as a DISPLAYable representation of the type, then in that
implementation you will see:
The object #<RECORD 343241> is a #<CLASS 671726>.
It's fields are:
CAPTAIN: #<RECORD 442425>
X-POS: 3142.776
Y-POS: 0.0
So my browser wasn't really portable after all.
It is true that the only formal property you can specify about the first
argument to MAKE-RECORD-TYPE is that you can read it back later. But
programming languages are more than just a denotational semantics.
MAKE-RECORD-TYPE has an infinite number of arguments left unspecified
(assuming we don't adopt a recent proposal), which seems to me plenty of
room to experiment. Why insist on overloading the first one?
∂06-Sep-89 0006 KMP@stony-brook.scrc.symbolics.com Baby-Doe and friends
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 6 Sep 89 00:05:44 PDT
Received: from STONY-BROOK.SCRC.Symbolics.COM by life.ai.mit.edu (4.1/AI-4.10) id AA13346; Wed, 6 Sep 89 02:26:17 EDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 652712; 6 Sep 89 02:27:04 EDT
Date: Wed, 6 Sep 89 02:26 EDT
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Subject: Baby-Doe and friends
To: Pavel.pa@xerox.com
Cc: rrrs-authors@life.ai.mit.edu
In-Reply-To: <890905-150831-2109@Xerox>
Message-Id: <19890906062646.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
A few buffered up comments relating to this conversation...
- I strongly prefer CALL-WITH-VALUES to WITH-VALUES because my
background in other languages says that WITH-xxx forms should
be macros or special forms which have special syntaxes, usually
including an implicit-block body.
Given WITH-INPUT-FROM-FILE and WITH-OUTPUT-TO-FILE, I can't
make an argument of internal naming inconsistency for Scheme,
but I can say that I would change the names of those two functions
at the drop of a hat because I think they're badly misnamed.
- I think I mentioned before, but I'll say it again because it's
not getting much notice:
(CALL-xxx continuation function)
would make infinitely more sense to me than
(CALL-xxx function continuation)
since it is the continuation which is being called with values.
The fact that the function is a function is only an incidental
artifact. [i.e., if we had a separate datatype THUNK such that
(THUNK exp) meant like (LAMBDA () exp) except that THUNKs were
not `called', they were `frobbed', I think it would still make
sense to say
(CALL-xxx continuation thunk)
but it would be totally icky to say
(CALL-xxx thunk continuation)
In this thought exercise, you'd want to say
(FROB-xxx thunk continuation)
I believe.]
On the issue of internal consistency, CALL-WITH-CURRENT-CONTINUATION
takes only one arg, so I I can't construct an argument about whether
that argument is the first or the last, but the parallel with FUNCALL
in Lisp of anything named CALL-xxx is too strong and I just think it
will cause immeasurable headache for any CALL-xxx to not be like FUNCALL.
- I have a problem with the morpheme "values" in the multiple values
terminology. It's the reason I suggested YIELD earlier.
Part of the issue is that every object passed along a data-flow
path is, in effect, a value, so it seems contrived and potentially
confusion-inducing to designate some of those as VALUES and leave
the rest to merely be values.
The way a language is spoken aloud among people who program in it
is important to me. The following interchange in Common Lisp would
seem `natural' ...
``What does the function FOO return?''
``It returns (VALUES).''
(pronounced the same as ``It returns values.'')
One learns that the word "values" in spoken speech is shorthand for
``no values.'' It's really yucky. The reason I prefer (YIELD . values)
is that it doesn't admit this bizaree verbal shorthand and properly
encourages one to say either
``It returns no values''
or ``It yields no values.''
- As for naming BABY-DOE, I still like COMPOSE-CONTINUATION.
(COMPOSE-CONTINUATION CONS (LAMBDA () (YIELD 1 2))) => (1 . 2)
If you really want a CALL-xxx thing, maybe I could get into
CALL-WITH-INTERVENING-CONTINUATION cont fn
Other possible adjectives include composed, interposed,
encapsulated, augmented, composed, protected, ...
- If a truncating version of BABY-DOE is created, I think some thought
should be given to whether it should also pad with extra NIL's or some
such. A key reason for using such a thing in the first place would
presumably be to interface to Common Lisp, which has the other kind
of multiple values, and provides both padding and truncation.
However, since this kind of truncation can be added as a layered thing,
I see no reason to include it in R4RS Scheme.
∂06-Sep-89 0626 ramsdell@linus.mitre.org Re: Baby-Doe and friends
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 6 Sep 89 06:26:42 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA02617; Wed, 6 Sep 89 09:08:05 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA16223; Wed, 6 Sep 89 09:08:52 EDT
Posted-Date: Wed, 06 Sep 89 09:02:06 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA10116; Wed, 6 Sep 89 09:02:07 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8909061302.AA10116@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Cc: ramsdell@linus.mitre.org
Subject: Re: Baby-Doe and friends
In-Reply-To: Your message of Wed, 06 Sep 89 02:26:00 -0400.
<19890906062646.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Wed, 06 Sep 89 09:02:06 EDT
It sounds to me that we all agree WITH-VALUES is no longer a viable
name for BABY-DOE.
>> From: Pavel.pa@xerox.com
...
>> John says, ``The important fact about BABY-DOE is not that it calls a
>> procedure with some values. Please verify my point by studying the formal
>> semantics.''
>>
>> I disagree completely; to my mind, that is the entire significance of
>> BABY-DOE. I don't see that there is anything ``unusual'' about the
>> continuation created by BABY-DOE. .....
At the begining of the search for a compromise on multiple values, we
all forgot that continuations should integrate with multiple values in
the natural way given by viewing BABY-DOE as a way of calling a thunk
with no arguments and a doctored continuation. This doctored
continuation is the result of prefixing the current continuation with
BABY-DOE's second argument. It is easy for the average user to assume
that Scheme's BABY-DOE is much like Common Lisp's MULTIPLE-VALUE-CALL,
but it is not. Let's find a name that will encourage users to make
the distinction.
I think the name CALL-WITH-CONTINUATION is too easily confused with
CALL-WITH-CURRENT-CONTINUATION. I like the name COMPOSE-CONTINUATION.
>> From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
...
>> - I have a problem with the morpheme "values" in the multiple values
>> terminology. It's the reason I suggested YIELD earlier.
I prefer YIELD to VALUES as well. When I tried to create a
description of VALUES, I found it strange writing about VALUES and its
value. Should we make this change, I hope there will not be a request
for CALL-WITH-YIELD as a name for BABY-DOE.
John
∂06-Sep-89 0821 gls@think.com Baby-Doe and friends
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 6 Sep 89 08:21:42 PDT
Received: from Think.COM (Gateway.Think.COM) by life.ai.mit.edu (4.1/AI-4.10) id AA03495; Wed, 6 Sep 89 11:11:45 EDT
Received: from fafnir.think.com by Think.COM; Wed, 6 Sep 89 11:12:25 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Wed, 6 Sep 89 11:09:49 EDT
Received: by verdi.think.com; Wed, 6 Sep 89 11:09:27 EDT
Date: Wed, 6 Sep 89 11:09:27 EDT
From: gls@think.com (Guy Steele)
Message-Id: <8909061509.AA22038@verdi.think.com>
To: KMP@stony-brook.scrc.symbolics.com
Cc: Pavel.pa@xerox.com, rrrs-authors@life.ai.mit.edu
In-Reply-To: Kent M Pitman's message of Wed, 6 Sep 89 02:26 EDT <19890906062646.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: Baby-Doe and friends
I applaud Kent's cogent attempt to find a rational terminology.
His point about the confusing uses of "VALUES" is well-taken.
Here is another approach to the question. Consider an intuitive
model in which arguments are "passed down" and values are
"returned up". (Yes, I know this runs afoul of the One True Way
of tail-recursion, but it suits my purposes here.)
Then we can describe the two proposed procedures in a reasonably symmetric
fashion: VALUES takes a set of objects headed downward as arguments and
bounces them back upward as values. (Think of a mirror. I would have said
"reflects" instead of "bounces" except the former already has another
technical meaning.) BABY-DOE takes a set of objects headed upward as
values and bounces them back downward as arguments.
I believe this symmetry to be quite real; the procedures seem asymmetric
only as a consequence of the asymmetry of function call notation, rather
than as a consequence of their intrinsic behaviors.
Therefore, if we retain the name VALUES for the one, one might reach the
logical, if not entirely aesthetic, conclusion that BABY-DOE should be
called ARGUMENTS.
--Guy
∂06-Sep-89 0859 katz@neon.stanford.edu Baby-Doe and friends
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 6 Sep 89 08:58:53 PDT
Received: from Neon.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA03861; Wed, 6 Sep 89 11:48:49 EDT
Received: by Neon.Stanford.EDU (5.61/25-eef) id AA01411; Wed, 6 Sep 89 08:48:59 -0700
Date: Wed, 6 Sep 89 08:48:59 -0700
From: Morris J. Katz <katz@neon.stanford.edu>
Message-Id: <8909061548.AA01411@Neon.Stanford.EDU>
To: rrrs-authors@life.ai.mit.edu
Subject: Baby-Doe and friends
While I am not particularly enthralled with the names WITH-VALUES
(CALL-WITH-VALUES) or VALUES, I find all of the suggested alternatives
to be far more distasteful than the original names. From my
perspective, the two function names should be both reasonably short
and pneumonically meaningful. Another name like
call-with-current-continuation is unacceptable because it is
unreasonably verbose.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂06-Sep-89 1018 @mc.lcs.mit.edu:hieb@iuvax.cs.indiana.edu mutiple values, procedures and continuations
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 6 Sep 89 10:18:18 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA04557; Wed, 6 Sep 89 13:10:04 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22473;
6 Sep 89 13:09 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 6 Sep 89 13:09:35 EDT
Received: from IUVAX.CS.INDIANA.EDU by mintaka.lcs.mit.edu id aa22454;
6 Sep 89 13:05 EDT
Received: by iuvax.cs.indiana.edu
Date: Wed, 6 Sep 89 12:04:41 -0500
From: Robert Hieb <hieb@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: mutiple values, procedures and continuations
Message-Id: <8909061305.aa22454@mintaka.lcs.mit.edu>
I think the mv discussion could be helped considerably by keeping
procedures and continuations distinct.
Scheme procedures are not continuations.
It is an artifact of continuation semantics (and cps implementations)
that a procedure call can be thought of as composing a continuation
and a procedure. Continuation semantics (and cps implemetations)
convert lambda-expressions to semantic functions which take
continuations as arguments. Other semantics (and implementations)
may not.
The second argument to "with-values" is no more a continuation than the
first argument. "with-values" need do no more continuation-mucking than
"apply".
Names need only hint at functionality. We can leave some description for
the report instead of trying to do it all in the name. "apply" is a good
example of a short name (it could have been "call-procedure-with-supplied-
values-and-values-from-list-and-send-result\(s\)-to-current-continuation").
"call-with-current-continuation" is a bad example of a short name
(which is why I say "call/cc" and you say "cwcc"). I am satisfied with
"with-values" unless someone can find something shorter and sweeter.
Following Guy's line of thought I was briefly tempted with "seulav"...
∂06-Sep-89 1428 @mc.lcs.mit.edu,@life.ai.mit.edu:bawden@arisia.xerox.com Baby-Doe and friends
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 6 Sep 89 14:28:36 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA06648; Wed, 6 Sep 89 17:04:55 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa25000;
6 Sep 89 16:46 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 6 Sep 89 16:46:53 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa24839;
6 Sep 89 16:33 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA06359; Wed, 6 Sep 89 16:33:30 EDT
Received: from arisia.Xerox.COM (arisia.xerox.com) by zurich.ai.mit.edu; Wed, 6 Sep 89 16:30:19 edt
Received: from roo.parc.Xerox.COM by arisia.Xerox.COM with SMTP
(5.61+/IDA-1.2.8/gandalf) id AA14707; Wed, 6 Sep 89 13:29:20 -0700
Received: from mr-bun.parc.Xerox.COM by roo.parc.xerox.com with SMTP
(5.61+/IDA-1.2.8/gandalf) id AA07366; Wed, 6 Sep 89 13:32:29 PDT
Date: Wed, 6 Sep 89 13:30 PDT
From: Alan Bawden <bawden@parc.xerox.com>
Subject: Baby-Doe and friends
To: rrrs-authors@zurich.ai.mit.edu
Cc: KMP@stony-brook.scrc.symbolics.com, Pavel.pa@xerox.com
In-Reply-To: <19890906062646.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-Id: <19890906203028.6.ALAN@MR-BUN.parc.xerox.com>
No one has yet suggested the name "RETURN" for the multiple-value creator.
Of course in Common Lisp the name is used for non-local exits, but it -is-
the verb that programmers commonly use to describe the act: "INTERN returns
two values".
(In fact, in older versions of ZetaLisp RETURN did -both- non-local exits
and multiple values, but in a fit of orthogonality (sounds painful!) that
feature was removed and made entirely the job of VALUES.)
To my ear, RETURN beats YIELD. To me YIELD is a word you see on traffic
signs where it makes a statement about rights.
As for BABY-DOE, I'm uncomfortable with any name that includes the word
"CONTINUATION" or that talks about "composition" of anything. Keep in mind
that unlike CALL-WITH-CURRENT-CONTINUATION, this is not a feature that only
Scheme wizards will use in bizare applications. We are adding multiple
values because we believe that ordinary programmers can benefit from using
this feature in mundane code, so the name needs to be convenient (unlike
CALL-WITH-CURRENT-CONTINUATION) and relevant to what programmers are using
BABY-DOE for. Programmers will be using BABY-DOE to recieve multiple
values; they will -not- be thinking in terms of continuations or about
composition of anything. Names like RECEIVE, RECEIVE-VALUES, WITH-VALUES
or even CALL-WITH-VALUES all seem to fit the bill.
It might be reasonable to adopt an inconvenient name, if a convenient
special form was also being proposed at the same time.
∂06-Sep-89 1619 @mc.lcs.mit.edu,@life.ai.mit.edu:jinx@zurich.ai.mit.edu Baby-Doe and friends
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 6 Sep 89 16:19:01 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA08115; Wed, 6 Sep 89 19:03:17 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa26236;
6 Sep 89 17:42 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 6 Sep 89 17:43:18 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa26219;
6 Sep 89 17:40 EDT
Received: from zurich.ai.mit.edu ([18.43.0.171]) by life.ai.mit.edu (4.1/AI-4.10) id AA07080; Wed, 6 Sep 89 17:40:15 EDT
Received: from localhost by zurich.ai.mit.edu; Wed, 6 Sep 89 17:37:05 edt
Date: Wed, 6 Sep 89 17:37:05 edt
From: "Guillermo J. Rozas" <jinx@zurich.ai.mit.edu>
Message-Id: <8909062137.AA10332@zurich.ai.mit.edu>
To: bawden@parc.xerox.com
Cc: rrrs-authors@zurich.ai.mit.edu, KMP@stony-brook.scrc.symbolics.com,
Pavel.pa@xerox.com
In-Reply-To: Alan Bawden's message of Wed, 6 Sep 89 13:30 PDT <19890906203028.6.ALAN@MR-BUN.parc.xerox.com>
Subject: Baby-Doe and friends
To my ear, RETURN beats YIELD. To me YIELD is a word you see on traffic
signs where it makes a statement about rights.
RETURN has too much of a connotation of "immediate exit no matter
where you are".
∂07-Sep-89 0942 @mc.lcs.mit.edu,@ZERMATT.lcs.mit.edu:ziggy@hx.lcs.mit.edu RE: name for VALUES
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 7 Sep 89 09:42:34 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA05047; Thu, 7 Sep 89 12:34:25 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa09237;
7 Sep 89 12:27 EDT
Received: from ZERMATT.LCS.MIT.EDU (CHAOS 17316) by MC.LCS.MIT.EDU 7 Sep 89 12:15:35 EDT
Received: from HX.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via INTERNET with SMTP id 287628; 7 Sep 89 12:15:04 EDT
Received: by hx.LCS.MIT.EDU (5.51/4.7); Thu, 7 Sep 89 12:13:15 EDT
Date: Thu, 7 Sep 89 12:13:15 EDT
From: "Michael R. Blair" <ziggy@hx.lcs.mit.edu>
Message-Id: <8909071613.AA19084@hx.LCS.MIT.EDU>
To: rrrs-authors@zermatt.lcs.mit.edu
Subject: RE: name for VALUES
I too am not fond of YIELD since it is used in CLU for a different
purpose: there it is used to return multiple values but a dynamically
computed number of them, and it returns them one at a time to a FOR
statement which iterates over these YIELDed values. The construct which
does such YIELDing of values is aptly named an ITERATER.
I do not think that RETURN implies EXIT since the manual is careful
to call nonlocal exits just that rather than calling them something
like "immediate returns". In my low-level mind it just implies that
the values are placed in the RETURN register(s) and the current pending
continuation is invoked.
I also think it would be odd to have a section on multiple value
RETURN in which the construct which does the returning is called
YIELD.
Perhaps something like MVRETURN (for Multiple-Value-RETURN) or
RETURN/MV or RWMV?
~Ziggy
∂07-Sep-89 1013 @mc.lcs.mit.edu,@life.ai.mit.edu:jar@zurich.ai.mit.edu Baby-Doe and friends
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 7 Sep 89 10:13:13 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA05621; Thu, 7 Sep 89 13:07:05 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa09652;
7 Sep 89 13:00 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 7 Sep 89 13:00:38 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa09623;
7 Sep 89 12:56 EDT
Received: from zurich.ai.mit.edu ([18.43.0.158]) by life.ai.mit.edu (4.1/AI-4.10) id AA05454; Thu, 7 Sep 89 12:56:58 EDT
Received: from localhost by zurich.ai.mit.edu; Thu, 7 Sep 89 12:53:46 edt
Date: Thu, 7 Sep 89 12:53:46 edt
From: Jonathan Rees <jar@zurich.ai.mit.edu>
Message-Id: <8909071653.AA04106@zurich.ai.mit.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: Baby-Doe and friends
Date: Wed, 6 Sep 89 13:30 PDT
From: Alan Bawden <bawden@parc.xerox.com>
No one has yet suggested the name "RETURN" for the multiple-value creator.
The T 3.0 release notes and implementation suggest it. They just
haven't appeared on this list. Originally T used VALUES, following
Zetalisp, but (if I remember correctly) the implementors were quite
happy to rename it to RETURN and enjoyed (and enjoy) writing code that
was so confusing to Maclisp/Zetalisp programmers. The inverse
procedure is called RECEIVE-VALUES, and there's a macro RECEIVE.
∂08-Sep-89 0426 ramsdell@linus.mitre.org ARGUMENTS/VALUES -> CONSUME/PRODUCE
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 8 Sep 89 04:26:16 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA01456; Fri, 8 Sep 89 07:16:58 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA08260; Fri, 8 Sep 89 07:17:41 EDT
Posted-Date: Fri, 08 Sep 89 07:10:55 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA11926; Fri, 8 Sep 89 07:10:57 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8909081110.AA11926@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Subject: ARGUMENTS/VALUES -> CONSUME/PRODUCE
In-Reply-To: Your message of Wed, 06 Sep 89 11:09:27 -0400.
<8909061509.AA22038@verdi.think.com>
Date: Fri, 08 Sep 89 07:10:55 EDT
I changed my mind and now agree that the name for BABY-DOE need not be
so descriptive as to distinguish between Common Lisp style and Scheme
style multiple values. Having "continuation" in the name for BABY-DOE
is a bit much.
>> From: gls@think.com (Guy Steele)
...
>> Then we can describe the two proposed procedures in a reasonably symmetric
>> fashion: VALUES takes a set of objects headed downward as arguments and
>> bounces them back upward as values. (Think of a mirror. I would have said
>> "reflects" instead of "bounces" except the former already has another
>> technical meaning.) BABY-DOE takes a set of objects headed upward as
>> values and bounces them back downward as arguments.
...
>> Therefore, if we retain the name VALUES for the one, one might reach the
>> logical, if not entirely aesthetic, conclusion that BABY-DOE should be
>> called ARGUMENTS.
>>
>> --Guy
>>
If we do not retain the name for VALUES, one could use Guy's logic to
name the two proposed procedures CONSUME and PRODUCE.
CALL-WITH-VALUES is fine by me but I wish we could find something
shorter. RETURN is my favorite alternative to VALUES. Using Guy's
logic, I guess the symmetric pair of names would then be CALL and
RETURN.
John
∂08-Sep-89 1024 @relay.cs.net,@tektronix.tek.com:adams@tekchips.labs.tek.com ARGUMENTS/VALUES -> CONSUME/PRODUCE
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 8 Sep 89 10:24:06 PDT
Received: from MIT.EDU (MIT.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA05259; Fri, 8 Sep 89 12:42:52 EDT
Received: from RELAY.CS.NET by MIT.EDU with SMTP
id AA20452; Fri, 8 Sep 89 12:42:30 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa14090; 8 Sep 89 11:42 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
id AA26946; Fri, 8 Sep 89 09:38:23 PDT
Received: by tekirl.labs.tek.com (5.51/7.1)
id AA00671; Fri, 8 Sep 89 09:42:43 PDT
Received: by tekchips.LABS.TEK.COM (5.51/6.24)
id AA14744; Fri, 8 Sep 89 09:43:24 PDT
Date: Fri, 8 Sep 89 09:43:24 PDT
From: Norman Adams <adams%tekchips.labs.tek.com@relay.cs.net>
Message-Id: <8909081643.AA14744@tekchips.LABS.TEK.COM>
To: ramsdell%linus.mitre.org@relay.cs.net
Cc: rrrs-authors%life.ai.mit.edu@relay.cs.net
In-Reply-To: ramsdell@linus.mitre.org's message of Fri, 08 Sep 89 07:10:55 EDT <8909081110.AA11926@huxley.mitre.org>
Subject: ARGUMENTS/VALUES -> CONSUME/PRODUCE
From: ramsdell@linus.mitre.org
CALL-WITH-VALUES is fine by me but I wish we could find something
shorter. RETURN is my favorite alternative to VALUES. Using Guy's
logic, I guess the symmetric pair of names would then be CALL and
RETURN.
Or CONTINUE and RETURN. This has gone on long enough that I have lost
any perspective about what good names would be. Aren't most people
going to CALL-WITH-VALUES via some syntactic extension anyway? If so,
a good but long name is OK.
-Norman
∂08-Sep-89 1318 KMP@stony-brook.scrc.symbolics.com ARGUMENTS/VALUES -> CONSUME/PRODUCE
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 8 Sep 89 13:18:18 PDT
Received: from STONY-BROOK.SCRC.Symbolics.COM by life.ai.mit.edu (4.1/AI-4.10) id AA08096; Fri, 8 Sep 89 15:55:01 EDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 654818; 8 Sep 89 15:55:55 EDT
Date: Fri, 8 Sep 89 15:55 EDT
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Subject: ARGUMENTS/VALUES -> CONSUME/PRODUCE
To: adams%tekchips.labs.tek.com@relay.cs.net
Cc: ramsdell@linus.mitre.org, Pavel.PA@xerox.com, bawden@parc.xerox.com,
RRRS-Authors@life.ai.mit.edu
In-Reply-To: <8909081643.AA14744@tekchips.LABS.TEK.COM>
Message-Id: <19890908195535.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Fri, 8 Sep 89 09:43:24 PDT
From: Norman Adams <adams%tekchips.labs.tek.com@relay.cs.net>
...
Or CONTINUE and RETURN. This has gone on long enough that I have lost
any perspective about what good names would be. Aren't most people
going to CALL-WITH-VALUES via some syntactic extension anyway? If so,
a good but long name is OK.
Actually, CONTINUE seems to me to be the right name for VALUES, not
for CALL-WITH-VALUES!
Consider the precedent in Fortran: it is a near no-op, whose only
purpose in life is to provide a syntactic way of attaching a label. By
analogy, the purpose of VALUES is only a syntactic device to provide a
way of shoehorning two value producing expressions in a place where only
one would otherwise fit. (Further, consider that in FORTRAN, CONTINUE
takes zero arguments, and then returns to its continuation, which is not
expecting any arguments. So the usages are even compatible. :-)
Getting back to Scheme, though, CONTINUE has the properties I want which
VALUES does not of being agnostic about the number of values. It also
has the property I want that RETURN does not, of not wrongly suggesting
an imperative transfer of control. It suggests that the evaluator will
go about business as usual, but with N values instead of the usual one.
For CALL-WITH-VALUES, I suggest the name should be
(CALL-WITH-CONTINUATION fn continuation)
where the idea would be to think of the second function as effectively
promoted to the status of a continuation. (When that continuation `runs out,'
the current continuation receives its values.)
(CALL-WITH-CONTINUATION (LAMBDA () (CONTINUE 1 2)) CONS)
=> (1 . 2)
I think this has a very nice look to it.
∂08-Sep-89 1329 @mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu Baby-Doe and friends
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 8 Sep 89 13:29:20 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA08369; Fri, 8 Sep 89 16:18:08 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa27757;
8 Sep 89 16:10 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 8 Sep 89 16:11:13 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa27546;
8 Sep 89 15:58 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA08173; Fri, 8 Sep 89 15:58:11 EDT
Received: from skinner.cs.uoregon.edu ([128.223.4.13]) by zurich.ai.mit.edu; Fri, 8 Sep 89 15:54:42 edt
Received: from spencer.cs.uoregon.edu by skinner.cs.uoregon.edu with SMTP
(5.59++/IDA-1.2.8) id AA18546; Fri, 8 Sep 89 12:58:12 PDT
Received: by spencer.cs.uoregon.edu; Fri, 8 Sep 89 12:57:55 PDT
Date: Fri, 8 Sep 89 12:57:55 PDT
From: will@cs.uoregon.edu
Message-Id: <8909081957.AA14302@spencer.cs.uoregon.edu>
To: rrrs-authors@zurich.ai.mit.edu
Subject: Baby-Doe and friends
I like the names RECEIVE-VALUES and VALUES. In response to Norman
Adams's question, I expect to call them directly instead of using
syntactic sugar. That's why I want the thunk to be the first
argument and the receiver the second, and that's why I don't like
the CALL-WITH-XXX names, which (sound like they) imply that the
receiver is the first argument.
We could do worse than ARGUMENTS and VALUES. While reading Guy's
message I though he was going to propose that Baby Doe be called
BOUNCES.
Peace, Will
∂08-Sep-89 1426 gls@think.com ARGUMENTS/VALUES -> CONSUME/PRODUCE
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 8 Sep 89 14:26:15 PDT
Received: from Think.COM (Gateway.Think.COM) by life.ai.mit.edu (4.1/AI-4.10) id AA08522; Fri, 8 Sep 89 16:32:33 EDT
Received: from fafnir.think.com by Think.COM; Fri, 8 Sep 89 16:33:13 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Fri, 8 Sep 89 16:30:20 EDT
Received: by verdi.think.com; Fri, 8 Sep 89 16:29:49 EDT
Date: Fri, 8 Sep 89 16:29:49 EDT
From: gls@think.com (Guy Steele)
Message-Id: <8909082029.AA08948@verdi.think.com>
To: KMP@stony-brook.scrc.symbolics.com
Cc: adams%tekchips.labs.tek.com@relay.cs.net, ramsdell@linus.mitre.org,
Pavel.PA@xerox.com, bawden@parc.xerox.com,
RRRS-Authors@life.ai.mit.edu
In-Reply-To: Kent M Pitman's message of Fri, 8 Sep 89 15:55 EDT <19890908195535.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: ARGUMENTS/VALUES -> CONSUME/PRODUCE
Date: Fri, 8 Sep 89 15:55 EDT
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
...
Actually, CONTINUE seems to me to be the right name for VALUES, not
for CALL-WITH-VALUES!
...
For CALL-WITH-VALUES, I suggest the name should be
(CALL-WITH-CONTINUATION fn continuation)
where the idea would be to think of the second function as effectively
promoted to the status of a continuation. (When that continuation `runs out,'
the current continuation receives its values.)
(CALL-WITH-CONTINUATION (LAMBDA () (CONTINUE 1 2)) CONS)
=> (1 . 2)
I think this has a very nice look to it.
Very nice indeed. A lot worse ideas have appeared (including mine).
Notice that the idiom for returning no values is thus (CONTINUE).
And I can write
(DO ((J 0 (+ J 1)))
((= J 10))
(DISPLAY J)
(DISPLAY (SQRT J))
(CONTINUE))
But I like it anyway.
Note that a "real" continuation can, if desired, be used as the
second argument to CALL-WITH-CONTINUATION, n'est-ce pas?
--Guy
∂08-Sep-89 1542 @relay.cs.net,@tektronix.tek.com:adams@tekchips.labs.tek.com name that baby
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 8 Sep 89 15:41:59 PDT
Received: from MIT.EDU (MIT.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA10069; Fri, 8 Sep 89 18:16:05 EDT
Received: from RELAY.CS.NET by MIT.EDU with SMTP
id AA21085; Fri, 8 Sep 89 18:15:42 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa20310; 8 Sep 89 17:13 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
id AA11445; Fri, 8 Sep 89 15:09:17 PDT
Received: by tekirl.labs.tek.com (5.51/7.1)
id AA04223; Fri, 8 Sep 89 15:13:37 PDT
Received: by tekchips.LABS.TEK.COM (5.51/6.24)
id AA16639; Fri, 8 Sep 89 15:14:18 PDT
Date: Fri, 8 Sep 89 15:14:18 PDT
From: Norman Adams <adams%tekchips.labs.tek.com@relay.cs.net>
Message-Id: <8909082214.AA16639@tekchips.LABS.TEK.COM>
To: RRRS-Authors%life.ai.mit.edu@relay.cs.net
Cc: adams@tekchips.labs
Subject: name that baby
Perhaps we should just go with the similarity of BABY-DOE and COMPOSE.
A multiple-values cognizant version of COMPOSE might be implemented as
(define (compose g f)
(lambda x (baby-doe (lambda () (apply g x)) f)))
(The argument order is the reverse of traditional COMPOSE.) The
result of COMPOSE is a function that accepts as many arguments as
G. The result of COMPOSE calls F on all the values returned by G.
Given this COMPOSE as primitive, we can define BABY-DOE as
(define (baby-doe thunk bunk)
((compose thunk bunk))
Why not make COMPOSE the primitive and flush BABY-DOE? Even with the
extra parens the name is half the length of "CALL-WITH-VALUE." Or if
those extra parens bother you -- how did you get this far? -- then
(define (compose-and-go a b)
((compose a b)))
Or how about this. If we are going to rename VALUES to CONTINUE, then
rename BABY-DOE to CONTINUE-FROM or CONTINUING. Then KMP's example
reads
(continuing (lambda () (continue 1 2)) cons)
But then why stop at two arguments? COMPOSE is usually n-ary.
(define (swap x y) (values y x))
(continuing (lambda () (continue 1 2)) swap cons)
=> (2 . 1)
-Norman
∂08-Sep-89 1759 KMP@stony-brook.scrc.symbolics.com name that baby
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 8 Sep 89 17:59:30 PDT
Received: from STONY-BROOK.SCRC.Symbolics.COM by life.ai.mit.edu (4.1/AI-4.10) id AA11732; Fri, 8 Sep 89 20:44:51 EDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 654998; 8 Sep 89 19:18:47 EDT
Date: Fri, 8 Sep 89 19:18 EDT
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Subject: name that baby
To: adams%tekchips.labs.tek.com@relay.cs.net
Cc: RRRS-Authors@life.ai.mit.edu
In-Reply-To: <8909082214.AA16639@tekchips.LABS.TEK.COM>
Message-Id: <19890908231830.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
CONTINUING is an ok substitue for my WITH-CONTINUATION. It seems to address
the criticisms markf had voiced for WITH-CONTINUATION, without sacrificing
any of the good properties I was worried about. I think your example shows
that making it be n-ary would be potentially quite convenient.
[I -especially- like the idea of using a form with a circular
tail to implement iteration. Borrowing on CL syntax:
(CONTINUING (LAMBDA () 1)
. #1=((LAMBDA (I) (PRINT (+ I 1))) . #1#))
:-]
∂11-Sep-89 0516 ramsdell@linus.mitre.org PIPE/CONTINUE
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 11 Sep 89 05:16:04 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA01885; Mon, 11 Sep 89 07:58:08 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA18336; Mon, 11 Sep 89 07:58:56 EDT
Posted-Date: Mon, 11 Sep 89 07:52:09 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA14518; Mon, 11 Sep 89 07:52:10 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8909111152.AA14518@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Subject: PIPE/CONTINUE
In-Reply-To: Your message of Fri, 08 Sep 89 15:14:18 -0700.
<8909082214.AA16639@tekchips.LABS.TEK.COM>
Date: Mon, 11 Sep 89 07:52:09 EDT
Given that I prefer having names for the multiple value procedures
which are descriptive enough so as to distinguish between Common Lisp
style and Scheme style multiple values, you correctly guess I like the
CONTINUING/CONTINUE pair. I especially like CONTINUE for the name of
the multiple value returner.
>> From: Norman Adams <adams%tekchips.labs.tek.com@relay.cs.net>
...
>> But then why stop at two arguments? COMPOSE is usually n-ary.
>>
>> (define (swap x y) (values y x))
>>
>> (continuing (lambda () (continue 1 2)) swap cons)
>> => (2 . 1)
We could use Unix terminology and the name PIPE. After all, BABY-DOE
connects two procedures using a "continuation pipeline".
(pipe (lambda () (continue 1 2)) swap cons)
=> (2 . 1)
John
∂11-Sep-89 0940 katz@neon.stanford.edu ARGUMENTS/VALUES -> CONSUME/PRODUCE
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 11 Sep 89 09:40:12 PDT
Received: from Neon.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AB04551; Mon, 11 Sep 89 12:08:13 EDT
Received: by Neon.Stanford.EDU (5.61/25-eef) id AA14343; Mon, 11 Sep 89 09:06:42 -0700
Date: Mon, 11 Sep 89 09:06:42 -0700
From: Morris J. Katz <katz@neon.stanford.edu>
Message-Id: <8909111606.AA14343@Neon.Stanford.EDU>
To: KMP@stony-brook.scrc.symbolics.com
Cc: adams%tekchips.labs.tek.com@relay.cs.net, ramsdell@linus.mitre.org,
Pavel.PA@xerox.com, bawden@parc.xerox.com,
RRRS-Authors@life.ai.mit.edu
In-Reply-To: Kent M Pitman's message of Fri, 8 Sep 89 15:55 EDT <19890908195535.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: ARGUMENTS/VALUES -> CONSUME/PRODUCE
I have tried to stay out of the naming battle because in general I
don't care about the names that much. However, I must comment that I
think that there is not enough Hamming distance between
CALL-WITH-CONTINUATION and CALL-WITH-CURRENT-CONTINUATION.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------
∂17-Sep-89 0101 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #205
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 17 Sep 89 01:01:18 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA12391; Sun, 17 Sep 89 00:10:04 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa07281;
17 Sep 89 0:05 EDT
Date: 17 SEP 89 00:05:57 EDT
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.lcs.mit.edu>
Subject: Scheme Digest #205
To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Message-Id: <8909170005.aa07281@mintaka.lcs.mit.edu>
Scheme Digest #205 17 SEP 89 00:05:57 EDT
Today's Topics:
Elk source available?
----------------------------------------------------------------------
Date: Sat, 16 Sep 89 11:05:07 +0200
From: Oliver Laumann <net%TUB.BITNET@mitvma.mit.edu>
Message-Id: <8909160905.AA08982@tub.UUCP>
Subject: Re: Elk source available?
> Some time ago there was mention of a package called ELK (Extensible
> Lisp Kernel ?), a standalone Scheme implementation intended to be
> the kernel of applications such as editors.
>
> Is this package available via FTP from anywhere ?
I have submitted the package to the moderator of comp.sources.unix about
two months ago. He has not yet posted it; in fact, the newsgroup seems
to be entirely dead. Thus I'm contemplating to post Elk to either
comp.sources.misc or alt.sources.
You can FTP the software from na-net.stanford.edu or patience.stanford.edu
(36.8.0.154); look into the directory pub/elk. I'm sending individual
copies by e-mail to sites without FTP access (but not over UUCP).
--
Oliver Laumann net@TUB.BITNET net@tub.UUCP
------------------------------
End of Scheme Digest
********************
∂17-Sep-89 0157 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #200
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 17 Sep 89 01:57:32 PDT
Received: from saturn.ucsc.edu by life.ai.mit.edu (4.1/AI-4.10) id AB09792; Fri, 15 Sep 89 22:38:05 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa14355;
12 Sep 89 0:47 EDT
Date: 12 SEP 89 00:05:37 EDT
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.lcs.mit.edu>
Subject: Scheme Digest #200
To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Message-Id: <8909120047.aa14355@mintaka.lcs.mit.edu>
Scheme Digest #200 12 SEP 89 00:05:37 EDT
Today's Topics:
FTP site for C Scheme?
FTP site for C Scheme?
Building Scheme
----------------------------------------------------------------------
From: gateh%CONNCOLL.BITNET@mitvma.mit.edu
Date: Mon, 11 Sep 89 09:52:22 EDT
Message-Id: <8909111352.AA06472@mvax.CONNCOLL.EDU>
Subject: FTP site for C Scheme?
Hello folks,
I recently posted a query concerning C Scheme, and I want to thank those
who responded. Being on BITNET, I had asked for info on sources _other_
than Internet FTP sites. It now appears that I may have FTP access to
Internet sites via a SERVer at PUCC, and so FTP source site addresses
for C Scheme would now be much appreciated. This is a good opportunity for
me to test this relatively new service. Once again, thanks for all your
help! - Gregg
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
Gregg TeHennepe | Academic Computing and User Services
Minicomputer Specialist | Box 5482
BITNET: gateh@conncoll | Connecticut College
Phone: (203) 447-7681 | New London, CT 06320
------------------------------
Date: 11 Sep 89 13:52:22 GMT
From: CONNCOLL.BITNET!gateh@bloom-beacon.mit.edu
Subject: FTP site for C Scheme?
Message-Id: <8909111352.AA06472@mvax.CONNCOLL.EDU>
Hello folks,
I recently posted a query concerning C Scheme, and I want to thank those
who responded. Being on BITNET, I had asked for info on sources _other_
than Internet FTP sites. It now appears that I may have FTP access to
Internet sites via a SERVer at PUCC, and so FTP source site addresses
for C Scheme would now be much appreciated. This is a good opportunity for
me to test this relatively new service. Once again, thanks for all your
help! - Gregg
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
Gregg TeHennepe | Academic Computing and User Services
Minicomputer Specialist | Box 5482
BITNET: gateh@conncoll | Connecticut College
Phone: (203) 447-7681 | New London, CT 06320
------------------------------
Date: 11 Sep 89 10:41:56 GMT
From: "Arto V. Viitanen" <eru!luth!sunic!tut!utacs!av@bloom-beacon.mit.edu>
Subject: Building Scheme
Message-Id: <741@utacs.UTA.FI>
Hello, I have a problem. I got a C-scheme distribution from ftp-machine
named sauna.hut.fi (in Finland). This distribution had two files, core.tar.Z
and exe-68k.tar.Z. They unpacked to directory dist-7.0, so this must be
version 7.0.
We have SUN-3 machines, so to compile scheme, I move to directory microcode
and copied file m/sun.h to m.h and file s/bsd.h to s.h (or something).
But when I typed ``make all'', I got following results:
make all
make -f xmakefile all
#** Generating cmp68020.s because of cmp68020.m4 cmp68020.m4
m4 cmp68020.m4 > cmp68020.s
#** Generating cmp68020.o because of cmp68020.s
as -1 -o cmp68020.o cmp68020.s
as: Unknown option '1' ignored.
as: Assembler Error-- Unrecognized address mode in:
lea _Registers,%a6
*** Error code 255
make: Fatal error: Command failed for target `cmp68020.o'
Current working directory /pd/av/scheme/dist-7.0/microcode
*** Error code 1
make: Fatal error: Command failed for target `doall'
Since I know nothing about 68020's assembly language, I turn to you. What
to do ?
Arto V. Viitanen
University Of Tampere, Department of Computer Science
av@utacs.uta.fi
------------------------------
End of Scheme Digest
********************
∂17-Sep-89 0321 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #204
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 17 Sep 89 03:21:08 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA11367; Sat, 16 Sep 89 00:29:15 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa00221;
16 Sep 89 0:05 EDT
Date: 16 SEP 89 00:05:57 EDT
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.lcs.mit.edu>
Subject: Scheme Digest #204
To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Message-Id: <8909160005.aa00221@mintaka.lcs.mit.edu>
Scheme Digest #204 16 SEP 89 00:05:57 EDT
Today's Topics:
Scheme Digest #169
----------------------------------------------------------------------
Date: Fri, 15 Sep 89 07:42 CST
From: RKIRCHNE@carleton.edu
Subject: RE: Scheme Digest #169
Message-ID: <8909150839.aa25733@mintaka.lcs.mit.edu>
This was the last Scheme Digest I've received. Our network has been
up and down, but I hope is up now. Could someone see that I get
put back on the mailing list and tell me how I can get the messages I've
missed? Thanks.
Roger Kirchner
------------------------------
End of Scheme Digest
********************
∂17-Sep-89 0410 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #199
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 17 Sep 89 04:10:16 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA08919; Fri, 15 Sep 89 20:23:25 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa14907;
10 Sep 89 0:05 EDT
Date: 10 SEP 89 00:05:17 EDT
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.lcs.mit.edu>
Subject: Scheme Digest #199
To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Message-Id: <8909100005.aa14907@mintaka.lcs.mit.edu>
Scheme Digest #199 10 SEP 89 00:05:17 EDT
Today's Topics:
ELK source available ?
----------------------------------------------------------------------
Date: 9 Sep 89 19:39:36 GMT
From: Kevin Esler <bucsb!esler@bu-cs.bu.edu>
Subject: ELK source available ?
Message-Id: <3225@bucsb.UUCP>
Some time ago there was mention of a package called ELK (Extensible
Lisp Kernel ?), a standalone Scheme implementation intended to be
the kernel of applications such as editors.
Is this package available via FTP from anywhere ?
------------------------------
End of Scheme Digest
********************
∂17-Sep-89 0412 @relay.cs.net,@tektronix.tek.com:kend@mrloog.wr.tek.com DOE-SEE-DOE and HEY-BABY!
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 17 Sep 89 04:12:50 PDT
Received: from MIT.EDU (MIT.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA05368; Thu, 14 Sep 89 13:38:38 EDT
Received: from RELAY.CS.NET by MIT.EDU with SMTP
id AA28673; Thu, 14 Sep 89 13:38:12 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id ab01016; 14 Sep 89 12:34 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
id AA04256; Thu, 14 Sep 89 09:17:08 PDT
Received: by wrgate.wr.tek.com (5.51/7.1)
id AA20144; Thu, 14 Sep 89 09:20:29 PDT
Received: by mrloog.WR.TEK.COM (1.2/7.1)
id AA04331; Thu, 14 Sep 89 09:22:03 pdt
Message-Id: <8909141622.AA04331@mrloog.WR.TEK.COM>
To: rrrs-authors%life.ai.mit.edu@relay.cs.net
Subject: DOE-SEE-DOE and HEY-BABY!
Date: 14 Sep 89 09:21:54 PDT (Thu)
From: kend%mrloog.wr.tek.com@relay.cs.net
=======
Preface:
=======
(define LIST-APPLY apply)
(define (VECTOR-APPLY proc vec) (list-apply proc (vector->list vec)))
===========
Observation:
===========
(LIST-APPLY cons (LIST 1 2)) --> (1 . 2)
(VECTOR-APPLY cons (VECTOR 1 2)) --> (1 . 2)
(VALUES-APPLY cons (VALUES 1 2)) --> (1 . 2)
========
Question:
========
If Form follows Function, does Name follow Form?
=====
Aside:
=====
I think that names such as APPLY-PROCEEDURE-TO-LIST are too long, but
might be persuaded that APPLY-TO-LIST is o.k. I prefer the shorter
forms, however.
-Ken Dickey kend@mrloog.WR.TEK.COM
note new domain ----↑↑
∂17-Sep-89 0413 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #203
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 17 Sep 89 04:13:27 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA08659; Fri, 15 Sep 89 19:42:16 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa18901;
15 Sep 89 0:26 EDT
Date: 15 SEP 89 00:05:41 EDT
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.lcs.mit.edu>
Subject: Scheme Digest #203
To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Message-Id: <8909150026.aa18901@mintaka.lcs.mit.edu>
Scheme Digest #203 15 SEP 89 00:05:41 EDT
Today's Topics:
Scheme-to-C Compiler -- More features, New license
----------------------------------------------------------------------
Message-Id: <8909150344.AA02149@jove.pa.dec.com>
Subject: Scheme-to-C Compiler -- More features, New license
Date: Thu, 14 Sep 89 20:44:30 PDT
From: bartlett@decwrl.dec.com
The Western Research Laboratory of Digital Equipment Corporation is
pleased to announce the general availability of its experimental
Scheme compiler. While we still require a signed license and a distribution
fee of $100, the new license is much in the spirit of the conditions under
which MIT releases CScheme. For example, the software is no longer
restricted to Digital manufactured systems.
The compiler compiles Revised**3 Scheme to C that is then compiled by
the native C compiler for the target machine. This design results in
a portable system that allows either stand-alone Scheme programs or
programs written in both compiled and interpreted Scheme and other
languages. An experiment run on a microVAX II suggests that this
approach does not adversely effect performance. There, the system
was able to execute the Gabriel benchmarks with performance similar
to that of a native Common LISP implementation.
The Scheme->C system supports the essentials of Revised**3 and many of the
optionals. Extensions include "expansion passing style" macros, a
foreign function call capability, and interfaces to X11's Xlib. The system
does provide call-with-current-continuation. Numbers are represented
internally as 29-bit integers, or 64-bit floating point values.
The system is oriented towards block compilation to generate code
which can run in standalone programs which may include code from
other languages. While debugging is typically done using the
interpreter, it will never be considered a "Scheme environment".
The one "wart" in the system is that the compiler cannot compile all
tail calls correctly. This follows from some of the design tradeoffs
made when mapping Scheme to C. For more details on this, see the technical
report is available from WRL (send the message "help" to the server at
WRL-Techreports@decwrl.dec.com).
The compiler is written in Scheme. Most of the runtime system
(including an interpreter) is written in Scheme. The generational garbage
collector and a few other things are written in C. There is a small
(< 100) amount of assembly code.
If you are interested in this software, please send me your postal address
and I will send you the licensing information.
Joel Bartlett bartlett@decwrl.dec.com
------------------------------
End of Scheme Digest
********************
∂21-Sep-89 0400 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #206
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Sep 89 04:00:13 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA01607; Thu, 21 Sep 89 06:10:16 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa07508;
19 Sep 89 1:00 EDT
Date: 19 SEP 89 00:06:14 EDT
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.lcs.mit.edu>
Subject: Scheme Digest #206
To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Message-Id: <8909190100.aa07508@mintaka.lcs.mit.edu>
Scheme Digest #206 19 SEP 89 00:06:14 EDT
Today's Topics:
CSCHEME on an Apollo ?
NET ACCESS AT OXFORD
scheme problem
----------------------------------------------------------------------
Date: 14 Sep 89 12:53:00 GMT
From: gupta <mcsun!ukc!stc!idec!prlhp1!gupta@uunet.uu.net>
Subject: CSCHEME on an Apollo ?
Message-Id: <976@prlhp1.prl.philips.co.uk>
Hi,
I recently got CSCHEME from M.I.T. via an info-server and am trying to
install it on an Apollo 3000 running BSD 4.2.
Has this been done ? The README file (dated 11/4/87) states it runs on
various Vax's, HP's and Sun's but I'm sure it must have been ported
to an Apollo in the interim two years.
I ran into problems running "make all" (step 4 of Install.unx).
The following is an edited transcript (loads of trailing Warnings deleted out).
------------------------------------------------------------
% make all
#** Resetting translate.touch because of config.h
touch translate.touch
#** Re-making Psbtobin because of translate.touch dump.c Psbtobin.c
rm -f Psbtobin
cc -Dunix -O -o Psbtobin Psbtobin.c -lm
#** Resetting scheme.touch because of scheme.h config.h bkpt.h object.h scode.h sdata.h gc.h interpret.h stack.h futures.h types.h errors.h returns.h const.h fixobj.h default.h extern.h prim.h
touch scheme.touch
#** Generating interpret.oo because of scheme.touch locks.h trap.h lookup.h history.h cmpint.h zones.h interpret.c
cc -c -Dunix -DDEFAULT_BAND_NAME=\"//node_97f2/local_user/gupta/lisp/scheme/scheme/runtime/scheme.bin\" -DSCHEME_SOURCES_PATH=\"//node_97f2/local_user/gupta/lisp/scheme/scheme/runtime/\" -DCOMPILE_HISTORY -O interpret.c
******** Line 249 of "default.h": Error: Malformed predicate for conditional compilation.
******** Line 253 of "default.h": Error: Malformed predicate for conditional compilation.
******** Line 257 of "default.h": Error: Malformed predicate for conditional compilation.
(0327) { { *--Reg_Stack_Pointer = ( Reg_Block[ 5]); *--Reg_Stack_Pointer = ( Reg_Block[ 6]); { if ( 0) { Print_Return(CONT_PRINT_RETURN_MESSAGE); Print_Expression( Reg_Block[ 5],
******** Line 327: [Warning #072] No path to statement "*".
******** Line 327: [Warning #072] No path to statement "Print_Return".
(0333) { *--Reg_Stack_Pointer = ( Reg_Block[ 5]); *--Reg_Stack_Pointer = ( Reg_Block[ 6]); { if ( 0) { Print_Return(CONT_PRINT_RETURN_MESSAGE); Print_Expression( Reg_Block[ 5],
*****
------------------------------------------------------------
The problem is that the file default.h is correct. It's as supplied - i.e. unedited by me.
This is what a part of it looks like :-
.
.
#ifndef Metering_Apply_Primitive
#define Metering_Apply_Primitive(Loc, N) \
Loc = Apply_Primitive(N)
#endif
#ifndef Eval_Ucode_Hook() /* **** THIS IS LINE 249 **** */
#define Eval_Ucode_Hook()
#endif
.
.
And it ALL looks OK. The error message suggests the compiler options are incorrect
so why point to default.h ?
Where do I go from here ?
I should say that I mainly code in Lisp and Smalltalk and so am not familiar
with the idiosyncracies of C and make.
Any help will be *appreciated*.
--
Ashok "Ash" Gupta
Post : Philips Research Labs, Crossoak Lane, Redhill, Surrey, RH1 5HA, U.K.
Voice: +44 293 785544 ext 5647
JANET: gupta@prl.philips.co.uk ARPA: gupta%prl.philips.co.uk@nsfnet-relay.ac.uk
------------------------------
Date: 17 Sep 89 18:48:09 GMT
From: Brian Leverich <leverich@RAND.ORG>
Subject: NET ACCESS AT OXFORD
Message-Id: <2201@randvax.UUCP>
I'll be visiting the Military History and International Relations
Department at Oxford's All Souls College this Michaelmas Term.
Unfortunately, they apparently have no machines with Net access. (I don't
think the department is exactly full of hackers... (-: ) Is anyone aware
of another department that might grant a guest account with Net access to
a visiting scholar with research interests in knowledge-based simulation
using ROSS-in-Scheme? Thanks! -B
--
"Simulate it in ROSS"
Brian Leverich | U.S. Snail: 1700 Main St.
ARPAnet: leverich@rand.org | Santa Monica, CA 90406
UUCP: decvax!randvax!leverich | Ma Bell: (213) 393-0411 X7769
------------------------------
Date: 18 Sep 89 21:03:15 GMT
From: gwusun!bleen.gwu.edu!stoler@uunet.uu.net
Subject: scheme problem
Message-Id: <1483@bleen.gwusun.gwu.edu>
I recently sent the following message out regarding a problem we were having
with our MIT cscheme installation. We haven't had any replies and I am
getting pretty desperate. If anyone has any suggestions, please advise.
Thanks in advance.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
We have recently attempted to install cscheme from MIT and all seemed to go
reasonably well until the end of the installation when the
script loaded scheme and then a bunch of files were
loaded and purified. After about 12 files we get the following
error message:
Purify phase error 9a0, 99f
numunp.bin loaded
Inconsistency detected
Error code 1
STOP
and scheme is unusable. When we try to invoke it she
bombs.
Any help would be appreciated.
Thanks.
Rich Stoler
------------------------------
End of Scheme Digest
********************
∂21-Sep-89 1251 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #208
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Sep 89 12:51:23 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA07714; Thu, 21 Sep 89 15:10:54 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa13523;
21 Sep 89 0:49 EDT
Date: 21 SEP 89 00:06:21 EDT
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.lcs.mit.edu>
Subject: Scheme Digest #208
To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Message-Id: <8909210049.aa13523@mintaka.lcs.mit.edu>
Scheme Digest #208 21 SEP 89 00:06:21 EDT
Today's Topics:
Looking for a MacIntosh Scheme
Why no eval?
Looking for a MacIntosh Scheme
----------------------------------------------------------------------
Date: 19 Sep 89 17:11:51 GMT
From: Melanie Stecker <thorin!unc!stecker@mcnc.org>
Subject: Looking for a MacIntosh Scheme
Message-Id: <9558@thorin.cs.unc.edu>
I am interested in finding Scheme for the MacIntosh,
(to run on a MacPlus at best) for use in a first year
programming course.
If you know of such a Scheme, please email me details.
If you have experience with the Scheme, especially in
an educational setting, please include a brief evaluation
of the software.
Depending on the response I receive, I will post a
summary of replies.
Thank you.
Melanie Stecker ************* stecker@cs.unc.edu
'On the loose to climb a mountain, on the loose where I am free,
on the loose to live my life the way I think my life should be...'
-Unknown
------------------------------
Date: 20 Sep 89 14:47:07 GMT
From: "Andrew L. M. Shalit" <apple!cambridge.apple.com!alms@bloom-beacon.mit.edu>
Subject: Re: Why no eval?
Message-Id: <ALMS.89Sep20104707@brazil.cambridge.apple.com>
In article <YZ5cNR600VsnI0cEgG@andrew.cmu.edu> bobg+@andrew.cmu.edu (Robert Steven Glickstein) writes:
Why does R↑3RS omit a specification for an EVAL procedure? It would
seem to have been omitted intentionally. What's the reasoning behind
this? Is there a trivial way to write an EVAL procedure?
EVAL requires access to environments, which Scheme doesn't currently
provide. Making environments first class (or even second-class but
accessible) is a very sticky problem, subject of much discussion
bordering on flamage. First class environments make analysis and
compilation harder, and they make it harder (impossible?) to understand
what a program could potentially do.
What uses for EVAL did you have in mind? There are probably other
ways to do what you want (unless you want to write a debugger). Also,
most implementations of Scheme do, in practice, support an EVAL of
sorts (for use in their read-eval-print loop, at least).
------------------------------
Date: 20 Sep 89 17:40:08 GMT
From: Paul Snively <usc!gem.mps.ohio-state.edu!apple!apple.com!chewy@bloom-beacon.mit.edu>
Subject: Re: Looking for a MacIntosh Scheme
Message-Id: <4250@internal.Apple.COM>
In article <9558@thorin.cs.unc.edu> stecker@unc.cs.unc.edu (Melanie
Stecker) writes:
> I am interested in finding Scheme for the MacIntosh,
> (to run on a MacPlus at best) for use in a first year
> programming course.
>
> If you know of such a Scheme, please email me details.
> If you have experience with the Scheme, especially in
> an educational setting, please include a brief evaluation
> of the software.
>
> Depending on the response I receive, I will post a
> summary of replies.
>
> Thank you.
> Melanie Stecker ************* stecker@cs.unc.edu
> 'On the loose to climb a mountain, on the loose where I am free,
> on the loose to live my life the way I think my life should be...'
> -Unknown
If you're talking about commercially-available implementations, the only
one that I'm familiar with is Lightship Software's (formerly Semantic
Microsystems') MacScheme family of products.
They have everything from Scheme Express, which is a very nice little
bytecode-interpreted system with a very nice little price tag ($69.95)
with a lot of cool things, such as a very simple, very elegant little
object system and a really cool nondeterministic programming system that
John Ulrich wrote (and wrote about in the September AI Expert, if my
memory serves me correctly). A bit higher up is MacScheme, which supports
native-code compilation for the Macintosh. Higher up still is
MacScheme+Toolsmith, which gives you high-level Macintosh Toolbox/OS
access and the ability to create standalone applications that can be
distributed without royalties.
Scheme Express sounds like it might be exactly what you need; it's
inexpensive and fits just fine in a one-megabyte Macintosh Plus. If you
want native code, you can go with MacScheme for $150; it will also work on
a one-meg machine. MacScheme+Toolsmith is $395 and will run in one meg,
but large programs may need more RAM.
I suggest that you contact Lightship Software at:
P.O. Box 1636
Beaverton, OR 97075
(503) 643-6909
Good luck!
__________________________________________________________________________
Just because I work for Apple Computer, Inc. doesn't mean that they
believe what I believe or vice-versa.
__________________________________________________________________________
------------------------------
End of Scheme Digest
********************
∂22-Sep-89 0517 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #209
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Sep 89 05:17:20 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA02410; Fri, 22 Sep 89 07:39:45 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa00762;
22 Sep 89 0:05 EDT
Date: 22 SEP 89 00:06:35 EDT
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.lcs.mit.edu>
Subject: Scheme Digest #209
To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Message-Id: <8909220005.aa00762@mintaka.lcs.mit.edu>
Scheme Digest #209 22 SEP 89 00:06:35 EDT
Today's Topics:
Elk on PMAX
----------------------------------------------------------------------
Date: 21 Sep 89 15:36:14 GMT
From: Dirk Grunwald <boulder.colorado.edu!grunwald@boulder.colorado.edu>
Subject: Elk on PMAX
Message-Id: <GRUNWALD.89Sep21093614@foobar.colorado.edu>
has any written the alloca-pmax.s and stack-pmax.c for Elk (embedded lisp
kernel) running on a PMAX?
If so, could you mail me a copy. Thanks.
Dirk Grunwald -- Univ. of Colorado at Boulder (grunwald@foobar.colorado.edu)
------------------------------
End of Scheme Digest
********************
∂28-Sep-89 1124 ramsdell@linus.mitre.org Naming BABY-DOE
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 28 Sep 89 11:23:50 PDT
Received: from linus.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA05290; Thu, 28 Sep 89 11:35:05 EDT
Return-Path: <ramsdell>
Received: from huxley.mitre.org by linus.mitre.org (5.59/RCF-3S)
id AA02963; Thu, 28 Sep 89 07:27:09 EDT
Posted-Date: Thu, 28 Sep 89 07:27:21 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA15565; Thu, 28 Sep 89 07:27:22 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8909281127.AA15565@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Subject: Naming BABY-DOE
In-Reply-To: Your message of Thu, 14 Sep 89 09:21:54 -0700.
<8909141622.AA04331@mrloog.WR.TEK.COM>
Date: Thu, 28 Sep 89 07:27:21 EDT
Shall we try to agree on an name for the multiple value procedures? I
suggest that I collect nominations, and then submit the names for an
E-mail vote. Let me begin by nominating a pair of names I know Pavel
supports.
---------------------------------------------------
Continuation Linker | Continuation Invoker.
------------------------|--------------------------
|
CALL-WITH-VALUES | VALUES.
|
---------------------------------------------------
∂28-Sep-89 1238 @relay.cs.net,@tektronix.tek.com:adams@tekchips.labs.tek.com Naming BABY-DOE oportunistically
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 28 Sep 89 12:38:20 PDT
Received: from MIT.EDU (MIT.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA07575; Thu, 28 Sep 89 14:49:03 EDT
Received: from relay.cs.net by MIT.EDU with SMTP
id AA01198; Thu, 28 Sep 89 14:48:26 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa04092; 28 Sep 89 13:47 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
id AA29003; Thu, 28 Sep 89 11:44:55 PDT
Received: by tekirl.labs.tek.com (5.51/7.1)
id AA03384; Thu, 28 Sep 89 11:47:17 PDT
Received: by tekchips.LABS.TEK.COM (5.51/6.24)
id AA14400; Thu, 28 Sep 89 11:48:21 PDT
Date: Thu, 28 Sep 89 11:48:21 PDT
From: Norman Adams <adams%tekchips.labs.tek.com@relay.cs.net>
Message-Id: <8909281848.AA14400@tekchips.LABS.TEK.COM>
To: rrrs-authors%life.ai.mit.edu@relay.cs.net
Subject: Naming BABY-DOE oportunistically
I really don't care as long as we choose some names. So, at any time,
I support the prevailing favorite names for the multiple values
procedures. -Norman
∂29-Sep-89 0350 ramsdell@linus.mitre.org Re: Naming BABY-DOE
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 29 Sep 89 03:50:23 PDT
Received: from linus.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA02114; Fri, 29 Sep 89 06:41:59 EDT
Return-Path: <ramsdell@linus.mitre.org>
Received: from huxley.mitre.org by linus.mitre.org (5.59/RCF-3S)
id AA02162; Fri, 29 Sep 89 06:41:53 EDT
Posted-Date: Fri, 29 Sep 89 06:42:04 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA17204; Fri, 29 Sep 89 06:42:05 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8909291042.AA17204@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Subject: Re: Naming BABY-DOE
In-Reply-To: Your message of Thu, 28 Sep 89 16:38:00 -0700.
<19890928233804.6.ALAN@MR-BUN.parc.xerox.com>
Date: Fri, 29 Sep 89 06:42:04 EDT
>> From: Alan Bawden <bawden@parc.xerox.com>
>> I presume we have all agreed that the order of arguments to BABY-DOE is
>> (BABY-DOE <generator> <receiver>)? That is, you are certain that nobody
>> thinks that certain names only make sense given certain argument orders?
I don't recall anyone supporting is call for the reverse argument
order, so I assume the one you gave is it. Of course, I could have
lost some mail....
John
∂29-Sep-89 0418 ramsdell@linus.mitre.org Re: Naming BABY-DOE
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 29 Sep 89 04:18:38 PDT
Received: from linus.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA02330; Fri, 29 Sep 89 07:01:51 EDT
Return-Path: <ramsdell@linus.mitre.org>
Received: from huxley.mitre.org by linus.mitre.org (5.59/RCF-3S)
id AA02332; Fri, 29 Sep 89 06:54:16 EDT
Posted-Date: Fri, 29 Sep 89 06:54:27 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA17240; Fri, 29 Sep 89 06:54:28 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8909291054.AA17240@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Subject: Re: Naming BABY-DOE
In-Reply-To: Your message of Fri, 29 Sep 89 06:42:04 -0400.
<8909291042.AA17204@huxley.mitre.org>
Date: Fri, 29 Sep 89 06:54:27 EDT
Let me try that again.
>> From: Alan Bawden <bawden@parc.xerox.com>
>> I presume we have all agreed that the order of arguments to BABY-DOE is
>> (BABY-DOE <generator> <receiver>)? That is, you are certain that nobody
>> thinks that certain names only make sense given certain argument orders?
I don't recall anyone supporting his (KMP's) call for the reverse
argument order, so I assume the one you gave is it. Of course, I
could have lost some mail....
John
∂29-Sep-89 1610 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #214
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 29 Sep 89 16:10:16 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA04121; Fri, 29 Sep 89 18:29:14 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa25484;
29 Sep 89 11:55 EDT
Date: 29 SEP 89 11:21:52 EDT
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.lcs.mit.edu>
Subject: Scheme Digest #214
To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Message-Id: <8909291155.aa25484@mintaka.lcs.mit.edu>
Scheme Digest #214 29 SEP 89 11:21:52 EDT
Today's Topics:
scheme 7.0 manual found
Invoking C-Scheme
----------------------------------------------------------------------
Date: 28 Sep 89 15:21:46 GMT
From: Gary M Pratt <m2c!wpi!gimp@husc6.harvard.edu>
Subject: scheme 7.0 manual found
Message-Id: <4332@wpi.wpi.edu>
Okay, the scheme 7.0 manual is at FTP site zurich.ai.mit.edu and is
located in the directory pub/scheme-7.0. The file is named man.tar.Z.
Also located in this directory are many files that are not located
at prep.ai.mit.edu.
Thanks go out to:
atheybey@PTT.LCS.MIT.EDU
& ange@hplb.hpl.hp.com Thu Sep 28 06:47:57 1989
------------------------------
Date: 28 Sep 89 19:02:42 GMT
From: Paul Stodghill <stodghil@cu-arpa.cs.cornell.edu>
Subject: Invoking C-Scheme
Message-Id: <32609@cornell.UUCP>
Two questions about MIT C-Scheme,
1) Is the only documentation available that which comes with the
distribution? In particular, the documentation for the run-time library
appears to be release notes and not a complete document. Also, there are
few sections in the reference manual which are blank and which I would like
to see.
2) I want some way to have scheme load and execute a file upon startup. How
can I do this? I know about the "-dump" option, but from what I understand
this just loads a dump and does not evaluate any expresion. Also dump files
are huge. I noticed in boot.c a "-fasl" option is mentioned, but it makes
some assumptions about the .bin file which I don't know.
------------------------------
End of Scheme Digest
********************
∂29-Sep-89 2236 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #215
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 29 Sep 89 22:36:09 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA07495; Sat, 30 Sep 89 00:46:35 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa05246;
30 Sep 89 0:31 EDT
Date: 30 SEP 89 00:07:00 EDT
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.lcs.mit.edu>
Subject: Scheme Digest #215
To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Message-Id: <8909300031.aa05246@mintaka.lcs.mit.edu>
Scheme Digest #215 30 SEP 89 00:07:00 EDT
Today's Topics:
Y combinator derivation
SICP: not hanging onto streams
----------------------------------------------------------------------
Date: 28 Sep 89 21:07:22 GMT
From: Dorai Sitaram <titan!dorai@rice.edu>
Subject: Re: Y combinator derivation
Message-Id: <1775@brazos.Rice.edu>
In article <27390@shemp.CS.UCLA.EDU> pierce@lanai.UUCP (Brad Pierce) writes:
$
$I think the previous poster was asking for a derivation of the
$*applicative-order* Y combinator, not the normal-order as given
$here. ``The Little Lisper'' (as someone else mentioned) has a
$good presentation, but its complexity points out the price pays
$for using an applicative-order language.
$
$In normal-order languages, like standard lambda calculus, the
$derivation is straightforward. The motivation for the Y-combinator
$in lambda calculus is to allow the use of recursive definitions.
$Recall that there is no such thing as assignment in lambda calculus,
$but that this elegant and mathematically tractable model of
$computation is rich enough to support recursion anyway.
$
$The standard example goes as follows:
$
$ [A quite proper description of normal-order Y deleted.]
$
$is the so-called Y-combinator given above. It is easy to verify
$the definition, as long as you remember that it is to be
$evaluated in normal-order. Finding a fixed-point combinator
$is not so easy when using applicative-order evaluation. Please see
$the ``Little Lisper''.
$
$Maybe it's time to start thinking seriously about whether the
$current performance benefits of applicative-order evaluation
$is worth the theoretical and human factors price tag.
I find your _conclusions_ (ie, not the body of your posting)
astounding. The applicative-order Y is not all that prohibitively more
complex than the normal-order one. One only has to replace in
$> Y = lambda h.(lambda x. h(x x))
$> (lambda x. h(x x)) .
both occurrences of (x x) by (lambda z. (x x) z). Note also that the
new Y shares the elegance and lack of assignment that you claim for
the old Y.
Re the current acceptance of applicative-order evaluation in the
world's programming languages, I hardly think it can be attributed
solely to performance benefits. Applicative-order is _understandable_
in the presence of side-effects in a way that normal-order fails to
be. You may protest that assignment-type side-effects should be
eliminated from the language, but then things like input and output
cannot be totally wished away.
Assuming you have a 'let' defined in the usual way in terms of lambda,
we have, in a potential normal-order real-life programming language
with input/output, among other things,
(let ([y (printf "y~n")])
((lambda (x) t) y))
never printing y at all;
(let ([y (printf "y~n")])
(or y y))
printing y twice (assuming printf returns nil);
whereas in applicative order, y is just printed once (as expected,
IMHO), regardless of the body of the let.
--dorai
-------------------------------------------------------------------------------
Alles ist richtig, auch das Gegenteil. Nur: zwar ... aber -- das ist
nie richtig. --Kurt Tucholsky
-------------------------------------------------------------------------------
------------------------------
Date: 29 Sep 89 18:04:48 GMT
From: Max Hailperin <Teknowledge.COM!polya!Neon.Stanford.EDU!max@beaver.cs.washington.edu>
Subject: SICP: not hanging onto streams
Message-Id: <12044@polya.Stanford.EDU>
This is really a SICP teaching question, not a scheme question, but
I bet this list reaches a lot of Structure and Interpretation of Computer
Programs instructors.
I noticed while teaching the material on streams that the examples are
very casual about pointing from the global environment at streams.
This (given memoization) results in excessive memory consumption, not
unlike in "Printing streams---A supplementary exercise for the
instructor" in the Instructor's Manual.
For example, to find the 100th integer not divisible by 7, we have
(define integers ...)
(define no-sevens (filter ... integers))
(nth-stream 100 no-sevens)
Wouldn't it be better to write
(define (generate-integers) ....)
(define (generate-no-sevens) (filter ... (generate-integers)))
(nth-stream 100 (generate-no-sevens))
?
Even for implicitly defined streams one can do something similar, e.g.
(define (generate-fibs)
(define fibs (cons-stream 0
(cons-stream 1
(add-streams (tail fibs)
fibs))))
fibs)
where the pointer to the whole stream is from an environment frame that
itself will stop being pointed at.
Of course, it is not the case that you want to do this indiscriminately. As
long as the stream generator takes time linear in the amount generated, then
there is no harm in regenerating the stream rather than saving it for resuse,
in big-O terms. However, there are cases where this wouldn't hold. You have
to be careful where to reuse and where not. For examle, the implicit
definition of fibs reuseses itself, because this only requires keeping a fixed
amount of state (the last two numbers) and reduces the time complexity from
exponential to linear. On the other hand, two seperate consumers of
fibonacci numbers might well each have calls to generate-fibs. For example,
we might write
(define (useless n m)
(- (nth-stream (* n m) (generate-fibs))
(sum-stream (substream n m (generate-fibs)))))
in order to keep the memory consuption fixed.
So, enough spouting off, time for the questions:
Has anyone else considered teaching this idiom?
Is there some problem with it that prevented you from doing so?
If not, how did it go?
Thanks very much.
------------------------------
End of Scheme Digest
********************
∂04-Oct-89 1545 KMP@stony-brook.scrc.symbolics.com Re: Naming BABY-DOE
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 4 Oct 89 15:41:50 PDT
Received: from STONY-BROOK.SCRC.Symbolics.COM by life.ai.mit.edu (4.1/AI-4.10) id AA03858; Wed, 4 Oct 89 15:46:07 EDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 669066; 4 Oct 89 15:09:01 EDT
Date: Wed, 4 Oct 89 15:08 EDT
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Subject: Re: Naming BABY-DOE
To: ramsdell@linus.mitre.org
Cc: rrrs-authors@life.ai.mit.edu, kmp@stony-brook.scrc.symbolics.com
References: <19890929202000.1.KMP@BOBOLINK.SCRC.Symbolics.COM>,
<8909291042.AA17204@huxley.mitre.org>
Message-Id: <19891004190853.1.KMP@BOBOLINK.SCRC.Symbolics.COM>
Retrying failed mail...
Date: Fri, 29 Sep 89 16:20 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Naming BABY-DOE
To: ramsdell@linus.mitre.org
cc: rrrs-authors@life.ai.mit.edu
In-Reply-To: <8909291042.AA17204@huxley.mitre.org>
Message-ID: <19890929202000.1.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Fri, 29 Sep 89 06:42:04 EDT
From: ramsdell@linus.mitre.org
>> From: Alan Bawden <bawden@parc.xerox.com>
>> I presume we have all agreed that the order of arguments to BABY-DOE is
>> (BABY-DOE <generator> <receiver>)? That is, you are certain that nobody
>> thinks that certain names only make sense given certain argument orders?
I don't recall anyone supporting is call for the reverse argument
order, so I assume the one you gave is it. Of course, I could have
lost some mail....
Depending on the function name, I support different argument orders.
For example,
(APPLY-TO-VALUES <receiver> <generator>)
(CALL-WITH-VALUES <receiver> <generator>)
but
(CONTINUING <generator> <receiver>)
(CALL-WITH-CONTINUATION <generator> <receiver>)
Note that I find no inconsistency in having one CALL-xxx thing take the
arguments in one order and another CALL-xxx thing take the arguments in
the other order. The basis of my preference is the following: APPLY
and CALL are verbs that take a direct object and an indirect object
(introduced by "with" or "to"). e.g., in the case of CALL-WITH-VALUES,
the direct object is the thing to be called and the indirect object
(introduced by "with") is the thing which generates the values. On the
other hand, CALL-WITH-CONTINUATION takes a direct object of a thing to
call and an indirect object (introduced by "with") of a continuation to
use.
I did a study of functions in the Lisp Machine system which have -WITH-
in their name. There are a zillion of them, and no explicit rules about
argument order, but statistically observed rules which suggest a linguistic
guiding principle consistent with that I cited in the previous paragraph.
I began to write up a more detailed analysis of the observed uses a while
back but decided that probably wouldn't care about the detail, so I filed
it away.
Btw, I don't like APPLY-VALUES because it's ambiguous whether "values"
is modifying arg1 as an adjective or whether there's an implicit "with"
or "to". A reasonable case can be made for either of
(APPLY-VALUES <generator> <receiver>)
or (APPLY-VALUES <receiver> <generator>)
which is conceptually dangerous for a function which takes two functions
as an argument--since the arguments sometimes can't be statically
(or even dynamically) detected to be in the wrong order.
Getting back to the original question, though...
My preference for the continuation invoker drives my preferences for the
other things, so it's a two-level sort...
1. Strong preference for CONTINUE to be the invoker. This is because it
is count-neutral, because it is not imperative, and because it suggests
a useful relationship with "continuations". I'm less fussy about
the name of the linker, but here is the breakdown on my current
thoughts anyway...
a. Moderately strong preference for CONTINUING (mostly because it
doesn't seem to confuse people in some of the ways that
CALL-WITH-CONTINUATION apparently does--also, it's short, which
CALL/CC fans must admit is a virtue.)
Example: (CONTINUING (LAMBDA () (CONTINUE 1 2)) CONS)
b. Slight lesser preference for COMPOSE-CONTINUATION.
Example: (COMPOSE-CONTINUATION CONS (LAMBDA () (CONTINUE 1 2)))
I'd also be willing to do some currying here.
((COMPOSE-CONTINUATION CONS) (LAMBDA () (CONTINUE 1 2)))
c. Slight lesser preference for CALL-WITH-CONTINUATION.
Example: (CALL-WITH-CONTINUATION (LAMBDA () (CONTINUE 1 2)) CONS)
If you're the sort to care about the possibility of extra args,
there's an issue here about whether if more arguments are added
they should be more continuations or just arguments to the first
function. My study of the LispM data suggests that people write
(frob-with-something frobee the-something frob-arg1 frob-arg2...)
e.g.,
(cook-with-recipe 'bread (recipe-of mom) :stove-type :electric)
The issue is whether you want to trade the occassional ease of
(CALL-WITH-CONTINUATION fn cont1 cont2 ...)
over
(CALL-WITH-CONTINUATION
(CALL-WITH-CONTINUATION fn cont1) con2)
for the ease of
(CALL-WITH-CONTINUATION CONTINUE CONS 1 2)
over
(CALL-WITH-CONTINUATION (LAMBDA () (CONTINUE 1 2)) CONS)
This may be all a red-herring.
2. Lesser but still noticeable preference for YIELD, primarily because
it doesn't have the problem of plural which VALUES (below) has.
The main problem here is that there is no similarly nice word which
describes the receipt of yielded values. I'm open to suggestions, though.
3. I dislike VALUES, but not as much as some other things. It's the "S" in
"VALUES" that really makes me dislike it. The fact that sometimes you
want to say VALUE and other times VALUES. But if VALUES -were- chosen, then
my preference is:
a. WITH-VALUES (mostly for symmetry with other WITH forms already in
Scheme). For better or worse, the argument order is also dictated
by those functions.
b. CALL-WITH-VALUES, APPLY-TO-VALUES, etc. are less good, but not terrible.
c. RECEIVE-VALUES and APPLY-VALUES are tolerable but not desireable, but
both suffer from the problem of no unique, intuitively dictated argument
order. If there were another like APPLY-LIST, APPLY-VECTOR, or something
in the language, it would improve the case for the name APPLY-VALUES--but
even then it would be weird because `values' is not a datatype like LIST
or VECTOR.
4. Strong dislike for things like RETURN and EXIT which suggest imperative
transfer of control. I want an operator which suggests a more passive
transfer of information.
Sorry about being so long-winded. I'm hoping this data will give you an
idea of how I think about all this and how I'm likely to receive new
suggestions or to react to some particular compromise.
∂07-Oct-89 0654 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #221
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 7 Oct 89 06:54:17 PDT
Received: from lcs.mit.edu ([18.26.0.36]) by life.ai.mit.edu (4.1/AI-4.10) id AA01116; Sat, 7 Oct 89 08:54:58 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa07295;
7 Oct 89 0:08 EDT
Date: 7 OCT 89 00:08:19 EDT
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.lcs.mit.edu>
Subject: Scheme Digest #221
To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Message-Id: <8910070008.aa07295@mintaka.lcs.mit.edu>
Scheme Digest #221 7 OCT 89 00:08:19 EDT
Today's Topics:
email contact for xscheme
----------------------------------------------------------------------
Date: 6 Oct 89 20:25:19 GMT
From: Ted Dunning <opus!ted@lanl.gov>
Subject: email contact for xscheme
Message-Id: <TED.89Oct6142519@kythera.nmsu.edu>
i am busy making some improvements to xscheme, but haven't found an
email address for the author, David Michael Betz. does anyone know if
he has an email address? or must i rely on hard post and phone?
--
ted@nmsu.edu +---------+
| In this |
| style |
|__10/6___|
------------------------------
End of Scheme Digest
********************
∂11-Oct-89 2309 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #223
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 11 Oct 89 23:09:03 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA18012; Thu, 12 Oct 89 01:40:52 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22896;
12 Oct 89 0:50 EDT
Date: 12 OCT 89 00:08:56 EDT
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.lcs.mit.edu>
Subject: Scheme Digest #223
To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Message-Id: <8910120050.aa22896@mintaka.lcs.mit.edu>
Scheme Digest #223 12 OCT 89 00:08:56 EDT
Today's Topics:
Elk on SUN4
Help a novice scheme programmer
----------------------------------------------------------------------
Date: Wed, 11 Oct 89 19:21:55 -0600
From: Harold Carr <carr%car@cs.utah.edu>
Message-Id: <8910120121.AA03621@car.utah.edu>
Subject: Elk on SUN4
Has anyone got ELK running on a Sun 4? Specifically the stack.s file
and any CFLAGS and LDFLAGS necessary. alloc.s should not be necessary
since it is supplied on sun OS 4.x.x - right?
I would appreciate pointers to or mail containing the required changes.
Thanks for you help:
Harold Carr
car@cs.utah.edu
------------------------------
Date: 11 Oct 89 23:09:37 GMT
From: Eric Griswold <ginosko!gem.mps.ohio-state.edu!apple!vsi1!frame!eeg@husc6.harvard.edu>
Subject: Help a novice scheme programmer
Message-Id: <3589@frame.UUCP>
I am teaching myself Scheme from the Dybvig book. After reading it
once through, I am doing the exercises. One near the beginning has
me stumped:
"A more elegant way to define cadr and cddr than given in this
section is to define a procedure that composes two procedures to
create a third. Whrite the procedure 'compose', such that
(compose proc1 proc2) is the composition of proc1 and proc2
[assuming both take one argument]. Use compose to define cadr and
cddr."
I give up. Please *MAIL* me a solution (hints and any other
pedantic messages don't count as solutions) && I will summarize if
appropriate.
------------------------------
End of Scheme Digest
********************
∂12-Oct-89 2201 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #224
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 12 Oct 89 22:01:48 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA06879; Fri, 13 Oct 89 00:28:04 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa10299;
13 Oct 89 0:08 EDT
Date: 13 OCT 89 00:09:05 EDT
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.lcs.mit.edu>
Subject: Scheme Digest #224
To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Message-Id: <8910130009.aa10299@mintaka.lcs.mit.edu>
Scheme Digest #224 13 OCT 89 00:09:05 EDT
Today's Topics:
On helping a novice scheme programmer
----------------------------------------------------------------------
Date: 12 Oct 89 17:55:22 GMT
From: Eric Griswold <vsi1!frame!eeg@AMES.ARC.NASA.GOV>
Subject: On helping a novice scheme programmer
Message-Id: <3591@frame.UUCP>
Thanks to all who sent me solutions. The fact that they were all
identical to my first try at the problem restores my faith in myself and
presents me with the nasty task of fixing my scheme interpreter.
I wasn't crazy or dense: it was.
------------------------------
End of Scheme Digest
********************
∂18-Oct-89 1500 cph@zurich.ai.mit.edu test message
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 18 Oct 89 14:59:41 PDT
Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA10764; Wed, 18 Oct 89 17:48:49 EDT
Received: from localhost by zurich.ai.mit.edu; Wed, 18 Oct 89 17:42:23 edt
Date: Wed, 18 Oct 89 17:42:23 edt
From: cph@zurich.ai.mit.edu (Chris Hanson)
Message-Id: <8910182142.AA29356@zurich.ai.mit.edu>
To: scheme-really-list@zurich.ai.mit.edu, rrrs-authors-list@zurich.ai.mit.edu,
scheme-standard-list@zurich.ai.mit.edu
Subject: test message
This is a test message -- please delete.
∂18-Oct-89 1506 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #227
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 18 Oct 89 15:05:52 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA10301; Wed, 18 Oct 89 17:16:10 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa20208;
18 Oct 89 0:34 EDT
Date: 18 OCT 89 00:10:20 EDT
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.lcs.mit.edu>
Subject: Scheme Digest #227
To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Message-Id: <8910180034.aa20208@mintaka.lcs.mit.edu>
Scheme Digest #227 18 OCT 89 00:10:20 EDT
Today's Topics:
xscheme bug
C Scheme sources wanted
----------------------------------------------------------------------
Date: 16 Oct 89 23:40:23 GMT
From: Brian of ASTD-CP <brian@topaz.rutgers.edu>
Subject: Re: xscheme bug
Message-Id: <1922@jato.Jpl.Nasa.Gov>
In article <362@nyit.UUCP> zilla@nyit.UUCP (John Lewis) writes:
|| there is a bug in xscheme0.17's (restore) function. the bug is
|| that garbage collection should be inhibited during the main part of
|| xlirestore(). This is because the image is restored in node-array
|| order, rather than obarray order. For example, strings may be
|| restored before the symbols which refer to them, and a gc before
|| the corresponding symbol is restored will remove the string (set
|| its type to FREE). routines called in xlirestore (e.g.
|| getvspace()) can trigger gc.
|| A fix is simply to set a flag inhibiting gc during the main part
|| of xlirestore. dbetz confirmed that this is a reasonable fix.
I'm glad someone brought this up again. This bug has been around
since 0.16, and a similar fix has been proposed before. This fix
D O E S N O T W O R K
at least, it does not work if you are restoring a work space requiring
more than a single vector segment (your workspace might be this big
if you have a lot of symbols).
The irony of the situation is that the bigger your workspace, the more
likely you are to need save/restore.
My analysis of the problem is incomplete, but my preliminary
indications are as follows:
* gc(), as a side effect, through gc_protect() and compact(), causes
the attributes of "vscurrent", the current vector segment, to
be set correctly, and it also sets the values of two global
variables, "vfree" and "vtop".
* If you inhibit garbage collection during restore, those variables
are not set correctly.
* Thus, on the first attempt to get more vector memory on behalf of
xlirestore(), xscheme errors with the message "insufficient
vector space". Really, there is more memory available. In fact,
malloc just returned a pointer to it. But "vfree" and "vtop" are
left pointing to the prior FULL segment, so when xscheme tries to
use the new vector memory, it finds it is STILL full.
I don't have a good solution to this. I don't even have a kludge
work around (yet). Anyone care to take a crack at solving this one?
. . . Brian Beckman . . . . . . . . . brian@topaz.jpl.nasa.gov. . .
. . . JPL Computer Graphics Lab. . . . (818) 397-9207. . . . . . . .
------------------------------
Date: 16 Oct 89 22:22:02 GMT
From: Darrell Long <agate!shelby!portia!midgard.ucsc.edu!darrell@ucbvax.berkeley.edu>
Subject: C Scheme sources wanted
Message-Id: <5898@portia.Stanford.EDU>
I'm looking for the sources to C Scheme. I'd like to use it in a class I will
be teaching next quarter.
I have FTP capability. Pointers to the source will be appreciated.
Thanks, DL
------------------------------
End of Scheme Digest
********************
∂18-Oct-89 2238 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #228
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 18 Oct 89 22:35:27 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA16174; Thu, 19 Oct 89 01:34:55 EDT
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Thu, 19 Oct 89 01:31:05 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa13290;
19 Oct 89 0:46 EDT
Date: 19 OCT 89 00:10:20 EDT
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.lcs.mit.edu>
Subject: Scheme Digest #228
To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Message-Id: <8910190046.aa13290@mintaka.lcs.mit.edu>
Scheme Digest #228 19 OCT 89 00:10:20 EDT
Today's Topics:
T3 on Sequent Symmetry or any i386?
T3 on Sequent Symmetry or any i386?
A better, free Scheme interpreter :-)
Looking for "literate programming" tools for Scheme/LISP
----------------------------------------------------------------------
Date: 17 Oct 89 18:02:05 GMT
From: Robert Kelley <tektronix!sequent!rjk@bloom-beacon.mit.edu>
Subject: T3 on Sequent Symmetry or any i386?
Message-Id: <23403@sequent.UUCP>
I was wondering if anyone has T working on a 386.
Please reply via e-mail. Thanks
Robert J. Kelley -- ...!uunet!sequent!rjk
------------------------------
Date: 17 Oct 89 18:02:05 GMT
From: Robert Kelley <tektronix!sequent!rjk@bloom-beacon.mit.edu>
Subject: T3 on Sequent Symmetry or any i386?
Message-Id: <23403@sequent.UUCP>
I was wondering if anyone has T working on a 386.
Please reply via e-mail. Thanks
Robert J. Kelley -- ...!uunet!sequent!rjk
------------------------------
Date: 18 Oct 89 16:24:00 GMT
From: Jonathan Lee <helios.ee.lbl.gov!pasteur!scheme.Berkeley.EDU!jonathan@ucsd.edu>
Subject: A better, free Scheme interpreter :-)
Message-Id: <18495@pasteur.Berkeley.EDU>
Fools' lisp is a scheme interpreter that follows, in most cases, the
R3RS standard. Although it is still under development, I think it is
useful as a light lisp (though it probably still has some bugs!).
One of the main features of this implementation is extensiblity. This
is achieved through a simple object oriented approach and a simple
primitive interface.
The code seems to be fairly portable: it works on a Sun 3 (running
either SunOS 3.x and 4.0.x), a DECstation 3100, a Sequent Symmetry,
and a VAX (running either Ultrix 3.x or BSD).
You can get your own free copy from scam.berkeley.edu (128.132.138.1) in
the ~ftp/src/local directory via anonymous ftp. The file is fools.tar.Z.
I welcome any suggestions or bug reports.
Thank you,
Jonathan Lee
jonathan@scheme.berkeley.edu
------------------------------
Date: 16 Oct 89 15:32:32 GMT
From: Patrick Logan <tektronix!sequent!mntgfx!plogan@bloom-beacon.mit.edu>
Subject: Looking for "literate programming" tools for Scheme/LISP
Message-Id: <1989Oct16.153232.19051@mentor.com>
(1) Does someone have WEB or equivalent set up for Scheme or another LISP?
(2) Do you know of any references to "literate programming" applied to
Scheme/LISP?
Thanks.
--
Patrick Logan | ...!{decwrl,sequent,tessi}!mntgfx!plogan
Mentor Graphics Corporation | plogan@pdx.MENTOR.COM
Beaverton, Oregon |
------------------------------
End of Scheme Digest
********************
∂19-Oct-89 2315 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #229
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 19 Oct 89 23:15:41 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA07160; Fri, 20 Oct 89 02:13:32 EDT
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Fri, 20 Oct 89 02:09:35 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa02481;
20 Oct 89 0:54 EDT
Date: 20 OCT 89 00:10:30 EDT
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.lcs.mit.edu>
Subject: Scheme Digest #229
To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Message-Id: <8910200054.aa02481@mintaka.lcs.mit.edu>
Scheme Digest #229 20 OCT 89 00:10:30 EDT
Today's Topics:
Looking for "literate programming" tools for Scheme/LISP
----------------------------------------------------------------------
From: ihlpn!rre@att.att.com
Date: Wed, 18 Oct 89 18:54 CDT
Message-ID: <8910190032.aa13033@mintaka.lcs.mit.edu>
Yo, hey.
I'm currently working on my graduate project back in Ann Arbor,
Michigan. If you need to urgenly (well, not *that* urgently) reach
me, I'll be checking email at
roger@caen.engin.umich.edu
I'll be back on Monday, October 23, 1989.
Hasta luego!
Roger Espinosa
------------------------------
Date: 19 Oct 89 15:00:12 GMT
From: Kellom{ki Pertti <eru!luth!sunic!tut!pk@bloom-beacon.mit.edu>
Subject: Re: Looking for "literate programming" tools for Scheme/LISP
Message-Id: <PK.89Oct19170012@korppi.tut.fi>
On 16 Oct 89 15:32:32 GMT,plogan@mentor.com (Patrick Logan) said:
Patrick> (1) Does someone have WEB or equivalent set up for Scheme or another LISP?
Patrick> (2) Do you know of any references to "literate programming" applied to
Patrick> Scheme/LISP?
I asked the same thing a while back, and this is the answer I got.
I've used SchemeTex quite a bit and I'm quite satisfied with it. If
you are interested, I've hacked it a bit to be used with GNU Texinfo,
and also cooked up some Emacs lisp support for dealing with SchemeTex
files. It is not at all ready to be released, but if you want to take
look at it, I'll be happy to share.
dorab> From: dorab@CS.UCLA.EDU (Dorab Patel)
..
dorab> i dont know if this helps, but ....
dorab> From: John D. Ramsdell <ramsdell%linus@mitre-bedford.ARPA>
dorab> Date: Mon, 18 Apr 88 09:22:39 EDT
dorab> Message-Id: <8804181322.AA11583@darwin.sun.uucp>
dorab> To: scheme@mc.lcs.mit.edu, texhax@score.stanford.edu
dorab> Subject: SchemeTeX---Simple support for literate programming in Lisp.
dorab> SchemeTeX provides simple support for literate programming in any
dorab> dialect of Lisp on Unix. Originally created for use with Scheme, it
dorab> defines a new source file format which may be used to produce LaTeX
dorab> code or Lisp code. Roughly speaking, LaTeX formats Lisp code in a
dorab> verbatum-like environment, and it formats Lisp comments in an ordinary
dorab> environment.
dorab> SchemeTeX is available via anonymous FTP from linus (192.12.120.51) in
dorab> the shar file named "pub/schemeTeX.sh". Included is an operating
dorab> system independent version for the T dialect of Lisp.
dorab> John
--
Pertti Kellom\"aki (TeX format) # These opinions are mine,
Tampere Univ. of TeXnology # ALL MINE !
Software Systems Lab # (but go ahead and use them, if you like)
------------------------------
End of Scheme Digest
********************
∂22-Oct-89 2037 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #230
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Oct 89 20:37:24 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA16281; Sun, 22 Oct 89 23:35:46 EDT
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Sun, 22 Oct 89 23:31:55 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa00265;
22 Oct 89 17:09 EDT
Date: 22 OCT 89 00:10:31 EDT
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.lcs.mit.edu>
Subject: Scheme Digest #230
To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Message-Id: <8910221709.aa00265@mintaka.lcs.mit.edu>
Scheme Digest #230 22 OCT 89 00:10:31 EDT
Today's Topics:
xscheme,xlisp save/restore bug?
ST xscheme binaries wanted
----------------------------------------------------------------------
Date: 20 Oct 89 05:48:04 GMT
From: John Lewis <snorkelwacker!usc!gem.mps.ohio-state.edu!sunybcs!sbcs!nyit!zilla@eddie.mit.edu>
Subject: xscheme,xlisp save/restore bug?
Message-Id: <363@nyit.UUCP>
There is a major bug in the xscheme (0.17) save/restore functions.
Since this code was adapted directly from Xlisp2.0, i'm wondering
whether there is a similar problem in Xlisp (& a fix, hopefully),
or why it isn't a problem.
i'm not sure i can characterize the bug very well (if i could i
would be on the way to fixing it), but my guess is that it involves
the interaction of garbage collection with restore- the image is
restored in node-array order, so collectable nodes may be restored
before the symbols they are attached to; garbage collection can
be triggered by creation of nodes during the restore, and this
GC can incorrectly free some of the partially restored image.
In any case, (restore) does not work (see recent mail on comp.lang.scheme).
Thanks for any advice
jp lewis@nyit computer graphics lab
516 686 7644(evenings)
------------------------------
Date: 20 Oct 89 16:26:16 GMT
From: eagle!ncastellano@bloom-beacon.mit.edu
Subject: ST xscheme binaries wanted
Message-Id: <2365@eagle.wesleyan.edu>
Hello...
WANTED:
Binaries for David Betz's XSCHEME on an Atari 520 | 1040 ST. Please point me
to an FTP source or mail me uuencoded / arced binaries directly. Also wanted:
ST binaries for ADVSYS by same author. I have all the docs/support/sources
for each, just need the binaries. (I don't have a reasonable C compiler.)
Thanks in advance,
NCASTELLANO@EAGLE.WESLEYAN.EDU
--
_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-
i believe in coyotes in time as an abstract explain the change the difference
between what you want and what you need there's the key your adventure for today
_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_R.-E._M.=_-_=
Nicholas Steven Castellano (dd) | ........................... | Disclaimer: I am
ncastellano@eagle.wesleyan.edu | ncastellano@wesleyan.bitnet | irresponsible.
_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-
------------------------------
End of Scheme Digest
********************
∂23-Oct-89 2215 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #231
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Oct 89 22:15:15 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA03721; Tue, 24 Oct 89 01:12:47 EDT
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Tue, 24 Oct 89 01:07:42 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22365;
24 Oct 89 0:30 EDT
Date: 24 OCT 89 00:10:50 EDT
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.lcs.mit.edu>
Subject: Scheme Digest #231
To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Message-Id: <8910240030.aa22365@mintaka.lcs.mit.edu>
Scheme Digest #231 24 OCT 89 00:10:50 EDT
Today's Topics:
port of ELK to 3b2 or PC/RT
Looking for "literate programming" tools for Scheme/LISP
Looking for "literate programming" tools for Scheme/LISP
----------------------------------------------------------------------
Date: 22 Oct 89 01:31:00 GMT
From: Andy Purshottam <andy@ernie.berkeley.edu>
Subject: port of ELK to 3b2 or PC/RT
Message-Id: <18649@pasteur.Berkeley.EDU>
Hi, anyone have a port of ELK to the 3b2 or the RT/PC?
Thanks,
Andy
------------------------------
Date: 23 Oct 89 17:55:45 GMT
From: Jeff Dalton <mcsun!ukc!edcastle!aiai!jeff@uunet.uu.net>
Subject: Re: Looking for "literate programming" tools for Scheme/LISP
Message-Id: <1271@skye.ed.ac.uk>
A while ago, I prepared some really simple tools for processing files
that were both documents and source code. The basic idea is to use a
verbatim environment (with *no* interesting processing) for code, but
under a different name. Consequently, it will work for any programming
language, but will never do any fancy formatting.
The idea is this: You write a ".ptex" file. Two "projections" are
defined for such files: one converts a ".ptex" file to a ".tex" file;
the other converts it to a ".lsp" (or whateverP file. Two new
environments are defined:
program -- converted directly to verbatim for ".tex";
contents outout as-is for ".lsp".
program-only -- like program, but discarded for ".tex"
All that's required are two AWK scripts and some entries in a
Makefile:
-------------------- Makefile entries --------------------
.SUFFIXES: .ptex .tex .lisp .lsp
.ptex.tex: ; awk -f totex < $*.ptex > $*.tex
.ptex.lsp: ; awk -f tocode < $*.ptex > $*.lsp
.ptex.lisp: ; awk -f tocode < $*.ptex > $*.lisp
-------------------- totex script --------------------
BEGIN { state="copy" }
state == "copy" && /↑ *\\begin{program}/ {print "\\begin{verbatim}"; break}
state == "copy" && /↑ *\\end{program}/ {print "\\end{verbatim}"; break}
state == "copy" && /↑ *\\begin{program-only}/ {state="ignore"; break}
state == "copy" {print; break}
/↑ *\\end{program-only}/ {state = "copy"; break}
-------------------- tocode script --------------------
BEGIN { state="ignore" }
state == "copy" && /↑ *\\end{program}/ {state = "ignore"; printf "\n"; break}
state == "copy" && /↑ *\\end{program-only}/ {state = "ignore"; printf "\n"; break}
state == "copy" {print; break}
/↑ *\\begin{program-only}/ {state = "copy"; break}
/↑ *\\begin{program}/ {state = "copy"; break}
-------------------- end --------------------
Simple, but can be effective.
Jeff Dalton, JANET: J.Dalton@uk.ac.ed
AI Applications Institute, ARPA: J.Dalton%uk.ac.ed@nsfnet-relay.ac.uk
Edinburgh University. UUCP: ...!ukc!ed.ac.uk!J.Dalton
------------------------------
Date: 22 Oct 89 19:58:35 GMT
From: Stephen Adams <mcsun!ukc!icdoc!sot-ecs!sra@uunet.uu.net>
Subject: Re: Looking for "literate programming" tools for Scheme/LISP
Message-Id: <SRA.89Oct22205835@alonzo.ecs.soton.ac.uk>
In article <1989Oct16.153232.19051@mentor.com> plogan@mentor.com
(Patrick Logan) writes:
(1) Does someone have WEB or equivalent set up for Scheme or another LISP?
(2) Do you know of any references to "literate programming" applied to
Scheme/LISP?
I have a solution for Common lisp. The same idea should work for most
lisps. I use the following code to read in latex files that have bits
of lisp code embedded in `lisp' or `program' environments. It works
by redefining the readtable so that
1. Latex comments are treated as comments in lisp .to treat latex
comment as lisp comments.
2. Anything starting with a `\' is a comment until the start of a
`lisp' or `program' environment.
It has been used under Sun Common Lisp (Lucid) and Kyoto Common Lisp.
I think that a full-blown WEB equivalent for lisp is a waste of time.
Much of what WEB offers is there to circumvent weaknesses in the host
language. Many lisp programs are declaration order independent (or
should be if you want to compile them). If you want to refine
something later functions and macros can be used.
Cheers
---- cut here, put it in latex.lisp -----
;
; Literate programming for common lisp and latex
;
; Only those bits of program in a `lisp' or `program' environment
; are loaded. This is achieved as follows:
;
; 1. `%' (the tex comment character) is make to act exactly like lisp's
; semicolon
; 2. `\' is make to skip text until a line containing only
; \begin{lisp}
; or \begin{program}
; The skipped text including the \begin bit is treated as a comment.
; 3. Devious code make the character dispatch read macro (#\... )
; still work. I hope.
;
;
; Re-building this file:
; On both lucid and kcl there are problems with overwriting the readtable
; while loading. It only seems to work properly if the functions are
; compiled and the readtable is updated in one operation. But that is
; a one-legged-chicken theory.
;
; To compile:
; Start lucid or KCL. (if you are already in lisp, exit & restart it)
; (compile-file "latex.lsp")
; either (bye) [in kcl] or (quit) [in lucid]
; Dont be tempted to load latex.{o,lbin} after compiling. It doesnt work.
;
; At any other time it is reasonable to load the compiled stuff.
;
(eval-when (compile) (proclaim '(optimize (safety 2))))
(defvar *default-hash-backslash-function*
(get-dispatch-macro-character #\# #\\))
(defun install-latex-readtable ()
(labels (
(backslash-mystifier (stream ch &aux line)
(unread-char ch stream)
(setf line (read-line stream nil nil t))
(loop
;;;; (format t "---> ~S~%" line)
(if (equal (peek-char nil stream nil 'T) 'T) (return (values)))
(setf line (read-line stream nil nil t))
(if (or (null line)
(string-equal line "\\begin{lisp}")
(string-equal line "\\begin{program}") )
(return (values)))
)
)
(grotty-new-character-reader (stream ch prefix &aux name (result nil))
(unwind-protect
(progn
(set-syntax-from-char #\\ #\\)
(set-dispatch-macro-character #\# #\\
*default-hash-backslash-function*)
(unread-char ch stream)
(setf name (read stream nil nil nil))
(setf prefix (if prefix (format nil "~D" prefix) ""))
(setf result (read-from-string
(format nil "#~A\\~A" prefix name)))
)
(progn
(set-macro-character #\\ #'backslash-mystifier nil)
(set-dispatch-macro-character #\# #\\
#'grotty-new-character-reader)
result))
))
(let ((newtable (copy-readtable nil)))
(set-syntax-from-char #\% #\; newtable newtable)
(set-macro-character #\\ #'backslash-mystifier nil newtable)
(set-dispatch-macro-character #\# #\\ #'grotty-new-character-reader
newtable)
(setf *readtable* newtable)
)))
(eval-when (load) (install-latex-readtable))
--
Stephen Adams S.Adams@uk.ac.soton.ecs (JANET)
Computer Science S.Adams@ecs.soton.ac.uk (Bitnet)
Southampton S09 5NH, UK S.Adams@sot-ecs.uucp (uucp)
------------------------------
End of Scheme Digest
********************
∂24-Oct-89 2208 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #232
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 24 Oct 89 22:07:59 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA22553; Wed, 25 Oct 89 01:06:44 EDT
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Wed, 25 Oct 89 01:01:48 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22266;
25 Oct 89 0:34 EDT
Date: 25 OCT 89 00:10:47 EDT
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.lcs.mit.edu>
Subject: Scheme Digest #232
To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Message-Id: <8910250034.aa22266@mintaka.lcs.mit.edu>
Scheme Digest #232 25 OCT 89 00:10:47 EDT
Today's Topics:
C Scheme sources wanted
Nisp compatibility package for standard Scheme?
Looking for "literate programming" tools for Scheme/LISP
----------------------------------------------------------------------
Date: 23 Oct 89 22:23:24 GMT
From: Eric Blossom <hpl-opus!hpccc!hpcc01!hpwrce!eric@hplabs.hp.com>
Subject: Re: C Scheme sources wanted
Message-Id: <380001@hpwrce.HP.COM>
This info is from the info-cscheme@zurich.ai.mit.edu mailing list:
|We've tested installation on the following machines, and would greatly
|appreciate any efforts that you could make getting things running on
|any other machines:
|
| HP 9000 series 300 and 800 running HP-UX
| Sun3 running SunOS
| Vax running Ultrix
| DS3100 running Ultrix
|
|This release may be obtained by anonymous ftp to "zurich.ai.mit.edu"
|(internet address 18.26.0.176), from the directory "pub/scheme-7.0/".
|See the README file in that directory for further directions.
|
------------------------------
Date: 24 Oct 89 20:26:53 GMT
From: Paul Wilson <Teknowledge.COM!polya!carcoar.Stanford.EDU!wilson@beaver.cs.washington.edu>
Subject: Nisp compatibility package for standard Scheme?
Message-Id: <12635@polya.Stanford.EDU>
Is there a version of Nisp for standard (e.g., Revised↑3 Report) Scheme?
(Nisp is a version of Lisp -- developed at Yale for AI programming --
for which there are several compatibility packages to make other Lisps look
like Nisp. I believe this includes Common Lisp and T, but I'm looking
for something that will allow me to run some serious programs in a
highly-instrumented but unextended Scheme system.)
Thanks prematurely,
Paul
Paul R. Wilson
Software Systems Laboratory lab ph.: (312) 996-9216
U. of Illin. at C. EECS Dept. (M/C 154) wilson@carcoar.stanford.edu
Box 4348 Chicago,IL 60680
------------------------------
Date: 24 Oct 89 16:40:15 GMT
From: Patrick Logan <tektronix!sequent!mntgfx!plogan@bloom-beacon.mit.edu>
Subject: Re: Looking for "literate programming" tools for Scheme/LISP
Message-Id: <1989Oct24.164015.6041@mentor.com>
In article <SRA.89Oct22205835@alonzo.ecs.soton.ac.uk> sra@ecs.soton.ac.uk (Stephen Adams) writes:
>> I think that a full-blown WEB equivalent for lisp is a waste of time.
>> Much of what WEB offers is there to circumvent weaknesses in the host
>> language. Many lisp programs are declaration order independent (or
>> should be if you want to compile them). If you want to refine
>> something later functions and macros can be used.
I came to the same conclusion. A couple of people also mailed similar
solutions. What I'm planning on now is to create my own with texinfo.
This way, there'll be a printed document, executable code, and an
"info" version of the document. It should facilitate a nice Scheme
library.
If anyone wants the finished product, send mail and I'll hold on to
your address. I'm not even going to guess at when I'll complete it.
Thanks very much to everyone who responded. I appreciate it.
--
Patrick Logan | ...!{decwrl,sequent,tessi}!mntgfx!plogan
Mentor Graphics Corporation | plogan@pdx.MENTOR.COM
Beaverton, Oregon |
------------------------------
End of Scheme Digest
********************
∂25-Oct-89 2200 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #233
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 25 Oct 89 22:00:24 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA09753; Thu, 26 Oct 89 00:55:27 EDT
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Thu, 26 Oct 89 00:50:27 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa19928;
26 Oct 89 0:35 EDT
Date: 26 OCT 89 00:10:53 EDT
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.lcs.mit.edu>
Subject: Scheme Digest #233
To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Message-Id: <8910260035.aa19928@mintaka.lcs.mit.edu>
Scheme Digest #233 26 OCT 89 00:10:53 EDT
Today's Topics:
Literate Programming in Scheme
Revised SchemeTeX Available
----------------------------------------------------------------------
Date: Wed, 25 Oct 89 10:06:21 EDT
From: Mitchell Wand <wand@corwin.ccs.northeastern.edu>
Message-Id: <8910251406.AA13215@corwin.CCS.Northeastern.EDU>
Subject: Literate Programming in Scheme
Here is a tiny ``literate programming'' package for Scheme. The basic idea is
that code sections are surrounded by |\ttcode| and |\endtt|. Then
there are a couple of filters: one to rip through a text and install the code
in indicated files, one just to filter the code out of a text, and a bit of
Chez scheme code to load through the appropriate filter.
There's not much here, but I've used it for writing a book chapter, and it
seemed to help a whole lot.
This all ought to run in LaTeX, except that it doesn't seem possible to hack
the |verbatim| environment to produce a |code| environment. If anyone knows
how to do this, please let me know!
Mitchell Wand
College of Computer Science
Northeastern University
360 Huntington Avenue #161CN
Boston, MA 02115
CSNet: wand@corwin.ccs.northeastern.edu
#!/bin/sh
# This is a shell archive.
# Run the file through sh to extract its contents.
# shar: Shell Archiver
# Run the following text with /bin/sh to create:
# lit-to-code
# lit-to-code.tex
# literate.tex
# lit-load.tex
# lit-to-scheme.tex
# tt.tex
# This archive created: Thu Oct 19 09:35:04 1989
echo shar: extracting lit-to-code '(162 characters)'
sed 's/↑XX//' << \SHAR_EOF > lit-to-code
XXawk '
XX/↑%filename/ {print "filename:", $2; filename = $2;}
XX/↑\\endtt/ {q = 0}
XX(q==1) {print filename "< " $0;
XX print $0 > filename;}
XX/↑\\ttcode/ {q=1}
XX' $*
XX
XX
XX
XX
SHAR_EOF
if test 162 -ne "`wc -c lit-to-code`"
then
echo shar: error transmitting lit-to-code '(should have been 162 characters)'
fi
echo shar: extracting lit-to-code.tex '(732 characters)'
sed 's/↑XX//' << \SHAR_EOF > lit-to-code.tex
XX\input sections
XX\input tt
XX\def\ttcode{\ttnoi}
XX%filename lit-to-code.a
XX
XX\sectionbegin {\tt lit-to-code}
XX
XXThis is a small {\tt awk} program to filter ``literate'' programs and install
XXthem in files. It uses the keyword {\tt \%filename} to mark the filename.
XXCode to be installed in the file is delimited by {\tt \\ttcode} and
XX{\tt \\endtt} (which must start at the beginning of the line). Code between
XXthese markers is installed in the indicated file.
XX
XXThe target file may be changed by just inserting a new {\tt
XX\%filename} command. The shell script will also take multiple source files as
XXarguments.
XX
XX\ttcode
XXawk '
XX/↑%filename/ {filename = $2}
XX/↑\\endtt/ {q = 0}
XX(q==1) {print $0 > filename}
XX/↑\\ttcode/ {q=1}
XX' $*
XX\endtt
XX
XX
XX
SHAR_EOF
if test 732 -ne "`wc -c lit-to-code.tex`"
then
echo shar: error transmitting lit-to-code.tex '(should have been 732 characters)'
fi
echo shar: extracting literate.tex '(231 characters)'
sed 's/↑XX//' << \SHAR_EOF > literate.tex
XX%%% macros for a tiny ``literate programming'' environment for Scheme. Code
XX%%% is delimited by \ttcode and \endtt (must be at beginning of line).
XX
XX\input tt
XX\define\ttcode{\ttnoi}
XX
XX%%% this is hardly worth a file, n'est-ce pas?
SHAR_EOF
if test 231 -ne "`wc -c literate.tex`"
then
echo shar: error transmitting literate.tex '(should have been 231 characters)'
fi
echo shar: extracting lit-load.tex '(591 characters)'
sed 's/↑XX//' << \SHAR_EOF > lit-load.tex
XX\input sections
XX\input tt
XX\def\ttcode{\ttnoi}
XX%filename lit-load.s
XX
XX\sectionbegin {\tt lit-load}
XX
XXThis is a small loader to load a ``literate'' scheme program. It merely takes
XXthe input file and pipes it through a small filter program called {\tt
XXlit-to-scheme}.
XX
XX\ttcode
XX(define lit-load
XX (lambda (filename)
XX (let* ((process-string
XX (string-append "lit-to-scheme " filename))
XX (process (process process-string))
XX (port (car process)))
XX (let loop ()
XX (let ((inp (read port)))
XX (if (eof-object? inp)
XX '()
XX (begin
XX (eval inp)
XX (loop))))))))
XX\endtt
XX
XX\bye
SHAR_EOF
if test 591 -ne "`wc -c lit-load.tex`"
then
echo shar: error transmitting lit-load.tex '(should have been 591 characters)'
fi
echo shar: extracting lit-to-scheme.tex '(438 characters)'
sed 's/↑XX//' << \SHAR_EOF > lit-to-scheme.tex
XX\input sections
XX\input tt
XX%filename lit-to-scheme
XX
XX\sectionbegin {\tt lit-to-scheme}
XX
XXThis is a small filter program for use with {\tt lit-load}. It just pipes the
XXsegments between instances of {\tt \\ttcode} and {\tt \\endtt} to the standard
XXoutput. It takes a single filename as as argument.
XX
XX{\bf Bug:} It will not do anything clever about protections.
XX
XX\ttcode
XXawk '
XX/↑\\endtt/ {q = 0}
XX(q==1)
XX/↑\\ttcode/ {q=1}
XX' $1
XX\endtt
XX
XX\bye
SHAR_EOF
if test 438 -ne "`wc -c lit-to-scheme.tex`"
then
echo shar: error transmitting lit-to-scheme.tex '(should have been 438 characters)'
fi
echo shar: extracting tt.tex '(2005 characters)'
sed 's/↑XX//' << \SHAR_EOF > tt.tex
XX\catcode`\↑↑I=\active % tab = \space
XX\def↑↑I{\space}
XX
XX\def\begindisplay{\obeylines\startdisplay}
XX{\obeylines\gdef\startdisplay#1
XX {\catcode`|↑↑M=5$$#1\halign\bgroup\indent##\hfil&&\qquad##\hfil\cr}}
XX\def\enddisplay{\crcr\egroup$$}
XX
XX\catcode`\|=\active
XX{\obeylines\gdef|{\ttverbatim\let↑↑M=\ \let|=\endgroup}}
XX
XX\chardef\other=12
XX\def\fullttverbatim{\begingroup \catcode`\\=\other \catcode`\{=\other
XX \def↑↑I{\ \ \ \ \ \ \ \ } % tab = 8 spaces
XX \catcode`\}=\other \catcode`\$=\other \catcode`\&=\other
XX \catcode`\#=\other \catcode`\%=\other \catcode`\~=\other
XX \catcode`\_=\other \catcode`\↑=\other
XX \obeyspaces \obeylines \tt}
XX{\obeyspaces\gdef {\ }} % \obeyspaces now gives \ , not \space
XX
XX\def\semittverbatim{\begingroup \catcode`\\=\other
XX \def↑↑I{\ \ \ \ \ \ \ \ } % tab = 8 spaces
XX \catcode`\&=\other
XX \catcode`\#=\other \catcode`\%=\other \catcode`\~=\other
XX \obeyspaces \obeylines \tt}
XX
XX\let\ttverbatim=\fullttverbatim
XX
XX\def\endline{\leavevmode\endgraf}
XX
XX\def\begintt{$$\let\par=\endline \ttverbatim \parskip=0pt
XX \catcode`\|=0 \rightskip=-5pc \ttfinish}
XX{\catcode`\|=0 |catcode`|\=\other % | is temporary escape character
XX |obeylines % end of line is active
XX |gdef|ttfinish#1↑↑M#2\endtt{#1|vbox{#2}|endgroup$$}}
XX
XX\def\tti{\let\par=\endline \ttverbatim \parskip=0pt
XX \catcode`\|=0 \rightskip=-5pc \ttifinish}
XX
XX\def\ttnos{\let\par=\endline \ttverbatim \parskip=0pt
XX \catcode`\|=0 \rightskip=-5pc \ttnosfinish}
XX
XX\def\beginttnoi{\begintt\parindent=0pt}
XX\def\ttnosi{\ttnos\parindent=0pt}
XX\def\ttnoi{\tti\parindent=0pt}
XX
XX\def\ttctr{$$\let\par=\cr \ttverbatim \parskip=0pt
XX \catcode`\|=0 \rightskip=-5pc \ttctrfinish}
XX
XX{\catcode`\|=0 |catcode`|\=\other % | is temporary escape character
XX |obeylines % end of line is active
XX |gdef|ttifinish#1\endtt{|endline #1 |endline|endgroup|noindent} %
XX |gdef|ttnosfinish#1\endtt{#1|endgroup|noindent} %
XX |gdef|ttctrfinish#1↑↑M#2\endtt{#1|vbox{|halign{##|hfil|cr#2}}|endgroup$$}}
XX
XX\def\semitt{\let\ttverbatim=\semittverbatim}
XX
XX\def\ttcode{\ttnoi}
SHAR_EOF
if test 2005 -ne "`wc -c tt.tex`"
then
echo shar: error transmitting tt.tex '(should have been 2005 characters)'
fi
# End of shell archive
exit 0
------------------------------
From: ramsdell@linus.mitre.org
Message-Id: <8910251844.AA01480@huxley.mitre.org>
Subject: Revised SchemeTeX Available
Date: Wed, 25 Oct 89 14:44:54 EDT
SchemeTeX---Simple support for literate programming in Lisp.
A new version of SchemeTeX is available. SchemeTeX provides simple
support for literate programming in any dialect of Lisp. Originally
created for use with Scheme, it defines a new source file format which
may be used to produce LaTeX input or Lisp code.
The distribution contains a Unix filter that translates SchemeTeX into
LaTeX which is independent of the Lisp dialect used. All SchemeTeX
comment lines can begin with ";", so that any Lisp reader can read the
source.
SchemeTeX source lines are divided into text and code. Lines of code
start with a line beginning with ``('', and continue until the line
containing the matching ``)''. The remaining lines are text lines,
and they are treated as comments.
The new version of SchemeTeX contains three programs written in R4R
Scheme. WEAVE translates SchemeTeX to LaTeX. TANGLE translates
SchemeTeX to Scheme. READ-ST is a SchemeTeX reader. You can use it
to load SchemeTeX source directly. These programs replace the
previous ones written in T.
You can obtain the distribution by sending mail to ramsdell@mitre.org.
SchemeTeX is no longer available via anonymous FTP.
John
------------------------------
End of Scheme Digest
********************
∂27-Oct-89 2120 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #234
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 27 Oct 89 21:20:04 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA12939; Sat, 28 Oct 89 00:14:05 EDT
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Sat, 28 Oct 89 00:09:13 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa06414;
28 Oct 89 0:09 EDT
Date: 28 OCT 89 00:11:07 EDT
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.lcs.mit.edu>
Subject: Scheme Digest #234
To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Message-Id: <8910280009.aa06414@mintaka.lcs.mit.edu>
Scheme Digest #234 28 OCT 89 00:11:07 EDT
Today's Topics:
GSScheme docs
----------------------------------------------------------------------
Date: 27 Oct 89 15:28:38 GMT
From: Yong Su Kim <CUNIXB.CC.COLUMBIA.EDU!yk4@ucbvax.berkeley.edu>
Subject: GSScheme docs
Message-Id: <8910271528.AA23672@cunixb.cc.columbia.edu>
I have managed to download the GSScheme but the documentation file
seems to have been corrupted since I cannot unpack it with Shrinkit yet
BINSCII returns no errors. If anyone has a copy of the docs, I would be
very grateful if they could e-mail a compressed copy.
Thanks.
_____________________________________________________________________________
|Internet: yk4@cunixb.cc.columbia.edu |||||||The Korean from Hong Kong.||||||
|Bitnet : yk4@cunixc |||||||||||||||||||||||||||||||||||||||
|UUCP : rutgers!columbia!cunixc!yk4 ||||||||||...Apple IIGS user...||||||||
|_______________________________________|||||||||||||||||||||||||||||||||||||||
------------------------------
End of Scheme Digest
********************
∂30-Oct-89 0639 ramsdell@linus.mitre.org Naming BABY-DOE
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 30 Oct 89 06:39:39 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA04715; Mon, 30 Oct 89 09:34:39 EST
Received: from linus.mitre.org (linus.mitre.org) by zurich.ai.mit.edu; Mon, 30 Oct 89 09:29:37 est
Received: from huxley.mitre.org by linus.mitre.org (5.59/RCF-3S)
id AA19115; Mon, 30 Oct 89 09:32:48 EST
Posted-Date: Mon, 30 Oct 89 09:32:38 EST
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA04562; Mon, 30 Oct 89 09:32:39 EST
From: ramsdell@linus.mitre.org
Message-Id: <8910301432.AA04562@huxley.mitre.org>
To: rrrs-authors@zurich.ai.mit.edu
Cc: ramsdell@linus.mitre.org
Subject: Naming BABY-DOE
Date: Mon, 30 Oct 89 09:32:38 EST
For the purpose of generating an agenda item at the next Scheme
meeting, I would like to select a single pair of names for the
multiple values procedures. Please vote for one of the pairs listed
below by putting your mark in one of the boxes in the Vote column and
mail your response directly to me at ramsdell@mitre.org. I will
report the results at the end of November by sending mail to this list.
- --------------------------------------------------------------------------
Continuation Linker | Continuation Invoker. | Generator first? | Vote
- ------------------------|-----------------------|------------------|------
| | |
CALL-WITH-VALUES | VALUES | yes |
| | |
- ------------------------|-----------------------|------------------|------
| | |
WITH-VALUES | VALUES | yes |
| | |
- ------------------------|-----------------------|------------------|------
| | |
CALL-WITH-VALUES | VALUES | no |
| | |
- ------------------------|-----------------------|------------------|------
| | |
CONTINUING | CONTINUE | yes |
| | |
- ------------------------|-----------------------|------------------|------
| | |
COMPOSE-CONTINUATION | CONTINUE | no |
| | |
- ------------------------|-----------------------|------------------|------
| | |
CALL-WITH-CONTINUATION | CONTINUE | yes |
| | |
- ------------------------|-----------------------|------------------|------
I hope this procedure will bring a reasonable quick resolution to
giving BABY-DOE a name.
John
∂30-Oct-89 1049 ramsdell@linus.mitre.org Naming BABY-DOE
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 30 Oct 89 10:49:12 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA08987; Mon, 30 Oct 89 13:44:10 EST
Received: from linus.mitre.org (linus.mitre.org) by zurich.ai.mit.edu; Mon, 30 Oct 89 13:39:15 est
Received: from huxley.mitre.org by linus.mitre.org (5.59/RCF-3S)
id AA23644; Mon, 30 Oct 89 13:42:28 EST
Posted-Date: Mon, 30 Oct 89 13:42:18 EST
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA04735; Mon, 30 Oct 89 13:42:19 EST
From: ramsdell@linus.mitre.org
Message-Id: <8910301842.AA04735@huxley.mitre.org>
To: rrrs-authors@zurich.ai.mit.edu
Subject: Naming BABY-DOE
Date: Mon, 30 Oct 89 13:42:18 EST
[This fixes the insert strangeness from replies by some mailers.
If you have already replied, you need not reply again. -JDR]
For the purpose of generating an agenda item at the next Scheme
meeting, I would like to select a single pair of names for the
multiple values procedures. Please vote for one of the pairs listed
below by putting your mark in one of the boxes in the Vote column and
mail your response directly to me at ramsdell@mitre.org. I will
report the results at the end of November by sending mail to this list.
|-------------------------------------------------------------------------
Continuation Linker | Continuation Invoker. | Generator first? | Vote
|-----------------------|-----------------------|------------------|------
| | |
CALL-WITH-VALUES | VALUES | yes |
| | |
|-----------------------|-----------------------|------------------|------
| | |
WITH-VALUES | VALUES | yes |
| | |
|-----------------------|-----------------------|------------------|------
| | |
CALL-WITH-VALUES | VALUES | no |
| | |
|-----------------------|-----------------------|------------------|------
| | |
CONTINUING | CONTINUE | yes |
| | |
|-----------------------|-----------------------|------------------|------
| | |
COMPOSE-CONTINUATION | CONTINUE | no |
| | |
|-----------------------|-----------------------|------------------|------
| | |
CALL-WITH-CONTINUATION | CONTINUE | yes |
| | |
|-----------------------|-----------------------|------------------|------
I hope this procedure will bring a reasonable quick resolution to
giving BABY-DOE a name.
John
∂30-Oct-89 1440 hal@zurich.ai.mit.edu forgive a stupid question, but ...
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 30 Oct 89 14:39:53 PST
Received: from zurich.ai.mit.edu ([18.43.0.179]) by life.ai.mit.edu (4.0/AI-4.10) id AA12938; Mon, 30 Oct 89 17:35:48 EST
Received: from localhost by zurich.ai.mit.edu; Mon, 30 Oct 89 17:30:45 est
Date: Mon, 30 Oct 89 17:30:45 est
From: hal@zurich.ai.mit.edu (Hal Abelson)
Message-Id: <8910302230.AA08973@zurich.ai.mit.edu>
To: rrrs-authors@zurich.ai.mit.edu
Subject: forgive a stupid question, but ...
Reply-To: hal@zurich.ai.mit.edu
.. could someone remind me just why it is in my better interests for
vector-ref and friends to signal an error when the index is an inexact
integer, rather than just silently coercing it to exact?
∂30-Oct-89 1530 bawden@arisia.xerox.com forgive a stupid question, but ...
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 30 Oct 89 15:29:59 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA13586; Mon, 30 Oct 89 18:25:55 EST
Received: from arisia.Xerox.COM (arisia.xerox.com) by zurich.ai.mit.edu; Mon, 30 Oct 89 18:21:02 est
Received: from roo.parc.Xerox.COM by arisia.Xerox.COM with SMTP
(5.61+/IDA-1.2.8/gandalf) id AA20223; Mon, 30 Oct 89 15:22:47 -0800
Received: from mr-bun.parc.Xerox.COM by roo.parc.xerox.com with SMTP
(5.61+/IDA-1.2.8/gandalf) id AA04255; Mon, 30 Oct 89 15:24:13 PST
Date: Mon, 30 Oct 89 15:21 PST
From: Alan Bawden <bawden@parc.xerox.com>
Subject: forgive a stupid question, but ...
To: hal@zurich.ai.mit.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: <8910302230.AA08973@zurich.ai.mit.edu>
Message-Id: <19891030232147.2.ALAN@MR-BUN.parc.xerox.com>
Date: Mon, 30 Oct 89 17:30:45 est
From: Hal Abelson <hal@zurich.ai.mit.edu>
.. could someone remind me just why it is in my better interests for
vector-ref and friends to signal an error when the index is an inexact
integer, rather than just silently coercing it to exact?
Suppose you were porting a program from an Scheme that had arbitrarily
large exact integers to one that only had 32-bit exact integers. Suppose
some intermediate result on the way towards computing a vector index
doesn't fit in 32 bits. Suppose the 32-bit Scheme handles such overflows
by converting to inexacts (perhaps using floating-point). Thus when you
arrive at the actual vector indexing operation, you've got an inexact
number. If we "silently coercing it to exact" there is no guarantee that
you will get the same exact integer you would have gotten in the original
Scheme implementation (assuming you are even lucky enough to get an integer
and not some random rational). If we "silently coercing it to exact" we
may silently introduce bugs.
You want that error to tell you that there was an unexpected excursion into
inexact arithmetic. If you -expected- an inexact number, you would have
called INEXACT->EXACT.
[ I am now bracing myself for another month arguing about inexact numbers
on this mailing list. I anticipate spending two or three months a year
for the rest of my life composing mail about this. ]
∂30-Oct-89 1609 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #235
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 30 Oct 89 16:09:30 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA01187; Mon, 30 Oct 89 02:00:16 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Mon, 30 Oct 89 01:28:47 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa01536;
30 Oct 89 0:41 EST
Date: 30 OCT 89 00:11:12 EST
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.lcs.mit.edu>
Subject: Scheme Digest #235
To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Message-Id: <8910300041.aa01536@mintaka.lcs.mit.edu>
Scheme Digest #235 30 OCT 89 00:11:12 EST
Today's Topics:
SchemeTeX
----------------------------------------------------------------------
From: ramsdell@linus.mitre.org
Message-Id: <8910271541.AA02879@huxley.mitre.org>
Subject: SchemeTeX
Date: Fri, 27 Oct 89 11:41:03 EDT
I got so many requests for SchemeTeX I decided to send it to the news
group. Since my last message, I modified the Scheme source to
SchemeTeX so that it contains no TAB characters for you Mac users.
Please update to this version even if you recently received a version
by mail from me.
John
#! /bin/sh
# This is a shell archive, meaning:
# 1. Remove everything above the #! /bin/sh line.
# 2. Save the resulting text in a file.
# 3. Execute the file with /bin/sh (not csh) to create the files:
# README
# Makefile
# astyped.sty
# schemeTeX.l
# st.sh
# st.scm
# st.tex
# reader.st
# This archive created: Fri Oct 27 11:35:30 1989
export PATH; PATH=/bin:$PATH
if test -f 'README'
then
echo shar: will not over-write existing file "'README'"
else
cat << \SHAR_EOF > 'README'
@(#)README 1.1 89/10/25
SchemeTeX---Simple support for literate programming in Lisp.
SchemeTeX is a Unix filter that translates schemeTeX source into LaTeX
source. Originally developed for the Scheme dialect of Lisp, it can
easily be used with most other dialects.
Installation:
1) Processes the file "st.tex" with LaTeX and read that one page
document.
2) Decide if you plan to use your Lisp system's standard LOAD
procedure or a modified one. I recommend you start by using your Lisp
system's LOAD, which means all text lines must begin with ";".
3) Assuming you do use the standard LOAD, edit "st.sh" so that it
contains the correct extension, i.e. ".scm", ".lisp", or ".clisp".
Otherwise do not modify "st.sh".
4) Edit "Makefile" to reflect the correct destination of the
executables(DEST) and the correct destination of the style
file(TEXDEST).
5) The command "make install" installs schemeTeX.
6) If you plan to modify your Lisp system's standard LOAD, follow the
model given in "reader.st", a reader of schemeTeX source for the R4RS
dialect of Scheme.
SHAR_EOF
fi # end of overwriting check
if test -f 'Makefile'
then
echo shar: will not over-write existing file "'Makefile'"
else
cat << \SHAR_EOF > 'Makefile'
# schemeTeX Makefile @(#)Makefile 1.4 89/10/25.
SRCS = README Makefile astyped.sty schemeTeX.l st.sh\
st.scm st.tex reader.st
CMDS = st schemeTeX
DOCS = st.dvi reader.dvi
TEXSTY = astyped.sty
#DEST = /usr/local/bin
DEST = $(HOME)/bin
#TEXDEST = /usr/local/lib/tex/inputs
TEXDEST = $(HOME)/doc/inputs
# Generic rules
.SUFFIXES: .dvi .tex .st
.st.dvi:
make $*.tex && make $*.dvi
.st.tex:
st $*
.tex.dvi:
latex $*
# Generic commands.
all: $(CMDS)
doc: $(DOCS) $(CMDS)
install: $(CMDS) $(TEXSTY)
mv $(CMDS) $(DEST)
cp $(TEXSTY) $(TEXDEST)
clean:
-rm $(CMDS)
dist: schemeTeX.sh
# Specific commands.
schemeTeX: schemeTeX.l
lex -t $? > schemeTeX.c
cc -O -o $@ schemeTeX.c -ll
rm schemeTeX.c
st: st.sh
cp $? $@
chmod +x $@
schemeTeX.sh: $(SRCS)
shar $(SRCS) > $@
SHAR_EOF
fi # end of overwriting check
if test -f 'astyped.sty'
then
echo shar: will not over-write existing file "'astyped.sty'"
else
cat << \SHAR_EOF > 'astyped.sty'
%%%%%%%%%%%%%%%%%%%%%% @(#)astyped.sty 1.3 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
% ASTYPED DOCUMENT-STYLE OPTION - released 88/06/30
% for LaTeX version 2.09
% Based on Leslie Lamport's verbatim environment in latex.tex.
% Defines the `astyped' environment, which is like the `verbatim'
% environment except most of the special characters have their usual meanings.
% Space, ↑K, and ↑A are the only specials changed.
\def\astyped{\trivlist \item[]\if@minipage\else\vskip\parskip\fi
\leftskip\@totalleftmargin\rightskip\z@
\parindent\z@\parfillskip\@flushglue\parskip\z@
\@tempswafalse \def\par{\if@tempswa\hbox{}\fi\@tempswatrue\@@par}
\obeylines \tt \catcode``=13 \@noligs \let\do\@makeother \do\ \do\↑↑K\do\↑↑A
\frenchspacing\@vobeyspaces}
\let\endastyped=\endtrivlist
% Used inside astyped environments for normal formatting of a line.
% I wish I could give space its normal catcode within \notastyped.
\def\notastyped#1{\mbox{\rm #1}}
SHAR_EOF
fi # end of overwriting check
if test -f 'schemeTeX.l'
then
echo shar: will not over-write existing file "'schemeTeX.l'"
else
cat << \SHAR_EOF > 'schemeTeX.l'
%{
/* schemeTeX -- Scheme to TeX. John D. Ramsdell.
* Simple support for literate programming in Scheme.
* Usage: schemeTeX < {Scheme TeX file} > {TeX file}
*/
#if !defined lint
static char ID[] = "@(#)schemeTeX.l 1.3 88/06/30";
static char copyright[] = "Copyright 1988 by The MITRE Corporation.";
/* Permission to use, copy, modify, and distribute this software and
its documentation for any purpose and without fee is hereby granted,
provided that the above copyright notice appear in all copies. The
MITRE Corporation makes no representations about the suitability of
this software for any purpose. It is provided "as is" without express
or implied warranty. */
#endif
/* SchemeTeX defines a new source file format in which source lines
are divided into text and code. Lines of code start with a line
beginning with '(', and continue until the line that contains the
matching ')'. The text lines remain, and they are treated as
comments. If the first character of a text line is ';', it is
stripped from the output. This is provided for those who want to use
an unmodified version of their Scheme system's LOAD. When producing a
document, both the text lines and the code lines are copied into the
document source file, but the code lines are surrounded by a pair of
formatting commands, as is comments beginning with ';' within code
lines. SchemeTeX is currently set up for use with LaTeX. */
/* Define STRIP if you want to remove all comments in a Scheme TeX
file. */
/* Modify the following for use with something other than LaTeX.
Also see tex_verbatim_echo. */
#define BEGIN_COMMENT "\\notastyped{"
#define BEGIN_CODE "\\begin{astyped}"
#define END_CODE "\\end{astyped}"
#define TEX_ECHO tex_verbatim_echo(yytext, stdout)
/* Lex is used for identifying code in an Scheme TeX file. */
int parens; /* Used to balance parenthesis. */
/* All input occurs in the following routines so that TAB characters
can be expanded. TeX treats TAB characters as a space--not what is
wanted. */
#undef getc()
#define getc(STREAM) expanding_getc(STREAM)
int spaces = 0; /* Spaces left to print a TAB. */
int column = 0; /* Current input column. */
int expanding_getc(stream)
FILE *stream;
{
int c;
if (spaces > 0) {
spaces--;
return ' ';
}
switch (c = fgetc(stream)) {
case '\t':
spaces = 8 - (7&column);
column += spaces;
return expanding_getc(stream);
case '\n':
column = 0;
return c;
default:
column++;
return c;
}
}
%}
%%
#\\\( {
#if defined STRIP
ECHO;
#else
TEX_ECHO;
#endif
}
#\\\) {
#if defined STRIP
ECHO;
#else
TEX_ECHO;
#endif
}
\( { ECHO; parens++; }
\) { ECHO; parens--;
if (parens == 0) { /* End of code. */
char c; /* Check that nothing follows. */
while ((c = input()) == ' ') output(c);
if (c == '\000') return 0; /* EOF */
if (c != '\n' && c != ';') return -1;
unput(c);
}
}
\"[↑"]*\" {
if ((yyleng > 1) && (yytext[yyleng-2] == '\\'))
yymore();
else
#if defined STRIP
ECHO;
#else
TEX_ECHO;
#endif
}
;[↑\n]*$ {
#if defined STRIP
;
#else
fputs(BEGIN_COMMENT, stdout);
ECHO;
fputs("}", stdout);
#endif
}
\n { ECHO; if (parens <= 0) return 0; }
. {
#if defined STRIP
ECHO;
#else
TEX_ECHO;
#endif
}
%%
fatal (s)
char *s;
{
fprintf(stderr, "On line %d, %s\n", yylineno, s);
exit(1);
}
tex_verbatim_echo (s, f)
char *s; FILE *f;
{
for (; *s != '\000'; s++)
switch (*s) {
case '\\':
case '{':
case '}':
case '$':
case '&':
case '#':
case '↑':
case '_':
case '%':
case '~':
fputs("\\verb-", f);
putc(*s, f);
putc('-', f);
break;
default: putc(*s, f);
}
}
main()
{
char c;
do { /* TeX mode and saw newline */
c = input();
if (c == '(') { /* TeX mode changed to code mode. */
unput(c);
#if !defined STRIP
fputs(BEGIN_CODE,stdout); putc('\n', stdout);
#endif
do { /* Copy out code using yylex. */
parens = 0;
if (0 != yylex()) fatal("Bad code section.");
if (parens != 0) fatal("Premature EOF.");
c = input();
unput(c); /* Repeat when there is code */
} while (c == '('); /* immediately after copied code. */
#if !defined STRIP
fputs(END_CODE, stdout); putc('\n', stdout);
#endif
}
else { /* Found a text line. */
if (c == ';') c = input(); /* For those who want to use bare load. */
while (c != '\n') {
if (c == '\000') exit(0); /* EOF. */
#if !defined STRIP
output(c);
#endif
c = input();
}
#if !defined STRIP
output(c);
#endif
}
} while (1);
}
SHAR_EOF
fi # end of overwriting check
if test -f 'st.sh'
then
echo shar: will not over-write existing file "'st.sh'"
else
cat << \SHAR_EOF > 'st.sh'
#! /bin/sh
# schemeTeX @(#)st.sh 1.3 88/06/30
EXT=.st
DIR=`dirname $1`
BASE=`basename $1 ${EXT}`
case $# in
0) schemeTeX ;;
1) schemeTeX < ${DIR}/${BASE}${EXT} > ${DIR}/${BASE}.tex ;;
2) schemeTeX < $1 > $2 ;;
*) echo "usage: $0 file-name"; exit 1;;
esac
SHAR_EOF
fi # end of overwriting check
if test -f 'st.scm'
then
echo shar: will not over-write existing file "'st.scm'"
else
cat << \SHAR_EOF > 'st.scm'
;;; @(#)st.scm 1.2 89/10/27
;;; SchemeTeX --- Simple support for literate programming in Scheme.
;;; October 1989, John D. Ramsdell.
;;;
;;; Copyright 1989 by The MITRE Corporation.
;;; Permission to use, copy, modify, and distribute this
;;; software and its documentation for any purpose and without
;;; fee is hereby granted, provided that the above copyright
;;; notice appear in all copies. The MITRE Corporation
;;; makes no representations about the suitability of this
;;; software for any purpose. It is provided "as is" without
;;; express or implied warranty.
;;;
;;; SchemeTeX
;;; defines a new source file format in which source lines are divided
;;; into text and code. Lines of code start with a line beginning with
;;; '(', and continue until the line that contains the matching ')'. The
;;; text lines remain, and they are treated as comments. When producing
;;; a document, both the text lines and the code lines are copied into
;;; the document source file, but the code lines are surrounded by a pair
;;; of formatting commands. The formatting commands are in begin-code
;;; and end-code. SchemeTeX is currently set up for use with LaTeX.
;;;
;;; Exports: tangle and weave.
;;; (tangle st-file scheme-file) Makes scheme file from schemeTeX source.
;;; (weave st-file tex-file) Makes LaTeX file from schemeTeX source.
(define (tangle st-filename scheme-filename) ; => scheme-filename or false.
(if (call-with-input-file st-filename
(lambda (st-port)
(call-with-output-file scheme-filename
(lambda (scheme-port)
(tangle-port st-port scheme-port)))))
scheme-filename
(begin ; Put a call to error here.
(display "tangle failed.") (newline)
'#f)))
(define (weave st-filename tex-filename) ; => tex-filename or false.
(if (call-with-input-file st-filename
(lambda (st-port)
(call-with-output-file tex-filename
(lambda (tex-port)
(weave-port st-port tex-port)))))
tex-filename
(begin ; Put a call to error here.
(display "weave failed.") (newline)
'#f)))
(define (tangle-port st-port scheme-port) ; => false on failure.
(letrec
((tex-mode-and-saw-newline ; Decide if input is code
(lambda ()
(let ((ch (peek-char st-port))) ; or tex source.
(cond ((eof-object? ch) '#t)
((char=? ch #\()
(scheme-mode))
(else (tex-mode-within-a-line))))))
(tex-mode-within-a-line ; Strip comments.
(lambda ()
(let ((ch (read-char st-port)))
(cond ((eof-object? ch) '#t)
((char=? ch #\newline)
(tex-mode-and-saw-newline))
(else (tex-mode-within-a-line))))))
(scheme-mode ; This routine should use
(lambda ()
(write (read st-port) scheme-port)
(newline scheme-port) ; read-refusing-eof if
(tex-mode-within-a-line)))) ; available.
(tex-mode-and-saw-newline)))
(define begin-code "\\begin{astyped}") ; TeX code surrounding
(define end-code "\\end{astyped}") ; code and comments
(define begin-comment "\\notastyped{") ; within code.
(define (weave-port st-port tex-port)
(let ((spaces 0) ; Used in get-char and get-line during
(hpos 0) ; the expansion of tabs into spaces.
(ch-buf '#f)) ; One char buffer.
(letrec
((get-char
(lambda () ; Get-char expands tabs into spaces,
(cond (ch-buf ; and implements a one character
(let ((ch ch-buf)) ; buffer.
(set! ch-buf '#f)
ch))
((> spaces 0)
(set! spaces (- spaces 1))
#\space)
(else
(let ((ch (read-char st-port)))
(cond ((eof-object? ch) ch)
((char=? ch #\tab) ; Expand tabs here.
(set! spaces (- 8 (modulo hpos 8)))
(set! hpos (+ hpos spaces))
(get-char))
((char=? ch #\newline)
(set! hpos 0)
ch)
(else
(set! hpos (+ hpos 1))
ch)))))))
(unget-char
(lambda (ch)
(set! ch-buf ch)))
(copy-line-saw-eof
(lambda ()
(let ((ch (get-char)))
(cond ((eof-object? ch) '#t)
((char=? ch #\newline) '#f)
(else
(write-char ch tex-port)
(copy-line-saw-eof))))))
(tex-write-char
(lambda (ch) ; Write to TeX file
(if (or (char=? ch #\\) ; escaping TeX's special
(char=? ch #\{) ; characters.
(char=? ch #\})
(char=? ch #\$)
(char=? ch #\&)
(char=? ch #\#)
(char=? ch #\↑)
(char=? ch #\_)
(char=? ch #\%)
(char=? ch #\~))
(begin
(display "\\verb-" tex-port)
(write-char ch tex-port)
(write-char #\- tex-port))
(write-char ch tex-port))))
;; TeX mode
(tex-mode-and-saw-newline ; State at which it is
(lambda () ; decided whether to go
(let ((ch (get-char))) ; into Scheme code mode
(cond ((eof-object? ch) '#t) ; or stay in TeX mode.
((char=? ch #\() (scheme-mode))
(else
;; Strip leading semicolon for those who
;; want to use regular load.
(if (not (char=? ch #\;))
(write-char ch tex-port))
(if (char=? ch #\newline)
(tex-mode-and-saw-newline)
(tex-mode-within-a-line)))))))
(tex-mode-within-a-line ; Copy out TeX line.
(lambda ()
(let ((saw-eof (copy-line-saw-eof)))
(newline tex-port)
(or saw-eof (tex-mode-and-saw-newline)))))
;; Scheme mode
(scheme-mode ; Change from TeX mode
(lambda () ; to scheme code mode.
(display begin-code tex-port)
(newline tex-port)
(write-char #\( tex-port)
(sexpr 1)))
(sexpr ; parens is used to watch
(lambda (parens) ; for the closing paren
(let ((ch (get-char))) ; used to detect the end
(cond ((eof-object? ch) '#f) ; of scheme code mode.
((char=? ch #\;)
(copy-comment-within-sexpr parens))
(else
(sexpr-write-char parens ch))))))
(copy-comment-within-sexpr
(lambda (parens) ; Handle comment.
(display begin-comment tex-port)
(write-char #\; tex-port)
(let ((saw-eof (copy-line-saw-eof)))
(write-char #\} tex-port)
(newline tex-port)
(and (not saw-eof) (sexpr parens)))))
(sexpr-write-char
(lambda (parens ch) ; Write a char and
(tex-write-char ch) ; figure out what to
(cond ((char=? ch #\() ; do next.
(sexpr (+ parens 1)))
((char=? ch #\))
(if (= 1 parens) ; Done reading sexpr.
(scheme-mode-after-sexpr)
(sexpr (- parens 1))))
((char=? ch #\")
(copy-out-string parens))
((char=? ch #\#) ; Worrying about #\( and #\).
(maybe-char-syntax parens))
(else (sexpr parens)))))
(copy-out-string
(lambda (parens)
(let ((ch (get-char)))
(and (not (eof-object? ch))
(begin
(tex-write-char ch)
(cond ((char=? ch #\\)
(let ((ch (get-char)))
(and (not (eof-object? ch))
(begin
(tex-write-char ch)
(copy-out-string parens)))))
((char=? ch #\")
(sexpr parens))
(else (copy-out-string parens))))))))
(maybe-char-syntax ; What out for
(lambda (parens) ; #\( and #\).
(let ((ch (get-char)))
(cond ((eof-object? ch) '#f)
((char=? ch #\\)
(tex-write-char ch)
(let ((ch (get-char)))
(and (not (eof-object? ch))
(begin
(tex-write-char ch)
(sexpr parens)))))
(else
(unget-char st-port)
(sexpr parens))))))
(scheme-mode-after-sexpr
(lambda ()
(let ((ch (get-char)))
(cond ((eof-object? ch) '#t)
((char=? ch #\;)
(copy-comment-after-sexpr))
((char=? ch #\newline)
(newline tex-port)
(scheme-mode-merge))
((char=? ch #\space)
(tex-write-char ch)
(scheme-mode-after-sexpr))
(else '#f))))) ; Call to error should go here.
(copy-comment-after-sexpr
(lambda () ; Handle trailing comment.
(display begin-comment tex-port)
(write-char #\; tex-port)
(let ((saw-eof (copy-line-saw-eof)))
(write-char #\} tex-port)
(newline tex-port)
(and (not saw-eof) (scheme-mode-merge)))))
(scheme-mode-merge ; Don't change mode if next
(lambda () ; line is code.
(let ((ch (get-char)))
(cond ((eof-object? ch) '#t)
((char=? ch #\() ; Stay in scheme mode.
(write-char ch tex-port)
(sexpr 1))
(else ; Enter tex mode.
(display end-code tex-port)
(newline tex-port)
(write-char ch tex-port)
(if (char=? ch #\newline)
(tex-mode-and-saw-newline)
(tex-mode-within-a-line))))))))
(tex-mode-and-saw-newline))))
SHAR_EOF
fi # end of overwriting check
if test -f 'st.tex'
then
echo shar: will not over-write existing file "'st.tex'"
else
cat << \SHAR_EOF > 'st.tex'
\documentstyle[proc]{article}
% @(#)st.tex 1.4 89/10/25
\title{Scheme\TeX{}}
\author{John D. Ramsdell}
\date{
89/10/25
}
\begin{document}
\maketitle
Scheme\TeX{} provides simple support for literate programming in any
dialect of Lisp. Originally created for use with Scheme, it defines a
new source file format which may be used to produce \LaTeX{} input or
Lisp code.
Scheme\TeX{} source lines are divided into text and code. Lines of code
start with a line beginning with ``('', and continue until the line
containing the matching ``)''. The remaining lines are text lines,
and they are treated as comments.
When producing a \LaTeX{} document, both the text lines and the code
lines are copied into the document source file, but the code lines are
surrounded by a pair of formatting commands (\verb-\begin{astyped}-
and \verb-\end{astyped}-). This \LaTeX{} environment formats the code
as written, in typewriter font. A Lisp comment within a code line is
formatted in an \verb-\mbox- in Roman font. A Scheme\TeX{} style
command should include the \verb-astyped- style option, so that the
\verb-astyped- environment is available. An example:
\begin{center}
\verb-\documentstyle[astyped]{article}-
\end{center}
Scheme\TeX{} was designed under the constraint that code lines must be
unmodified Lisp code, and text lines must be unmodified \LaTeX{} code.
Text editors with support for Lisp and \LaTeX{}, such as Emacs, may be
used for Scheme\TeX{} code much as they are used for Lisp code and
\LaTeX{} code.
For those who prefer not to modify the reader used by their Lisp
system's loader and compiler, the rule that text lines must be
unmodified \LaTeX{} code has been relaxed. Text lines that begin with
``;'' are copied without the initial ``;''.
\section*{Usage in Scheme}
The file \verb;st.scm; contains programs used to obtain code or
\LaTeX{} from a Scheme\TeX{} source file. The Scheme expression
\begin{center}
\verb;(TANGLE; {\it st-filespec Scheme-filespec\/}{\tt )}
\end{center}
creates Scheme source from a Scheme\TeX{} file, and the expression
\begin{center}
\verb;(WEAVE; {\it st-filespec \LaTeX{}-filespec\/}{\tt )}
\end{center}
creates LaTeX{} source.
The file \verb-reader.st- contains a Scheme\TeX{} reader in R$↑4$R Scheme.
Use that reader with your Scheme system's loader and compiler to
avoid running \verb-TANGLE- and creating a temporary file.
\section*{Usage in a Unix shell}
The extension for Scheme\TeX{} files is ``\verb;.st;''.
A \LaTeX{} file is produced from Scheme\TeX{} source
using the Unix shell command
\begin{center}
{\tt st} {\it file-name}
\end{center}
It will produce a file with the ``\verb;.tex;'' extension. The
obvious make file is in Figure~\ref{makefile}.
\begin{figure}
\begin{verbatim}
.SUFFIXES: .dvi .tex .st
.st.dvi:
make $*.tex && make $*.dvi
.st.tex:
st $*
.tex.dvi:
latex $*
\end{verbatim}
\caption{A Scheme\TeX{} Makefile}\label{makefile}
\end{figure}
\end{document}
SHAR_EOF
fi # end of overwriting check
if test -f 'reader.st'
then
echo shar: will not over-write existing file "'reader.st'"
else
cat << \SHAR_EOF > 'reader.st'
\documentstyle[astyped]{article}
% @(#)reader.st 1.4 89/10/25
\title{{\tt read-st}}
\author{John D. Ramsdell}
\date{
89/10/25
}
\begin{document}
\maketitle
\verb;read-st; converts Scheme\TeX{} representations of Scheme objects
into the objects themselves much as \verb;read; does.
(define (read-st . rest) ; Returns what \verb;read; returns.
(let ((port (if (pair? rest) ; \verb;read-st; arguments are
(car rest) ; the same as \verb;read;'s.
(current-input-port))))
(letrec
((text-mode-and-saw-newline ; Lines of a Scheme\TeX{} file
(lambda () ; beginning with ``{\tt(}'',
(let ((ch (peek-char port))) ; start a code section.
(cond ((eof-object? ch) ch)
((char=? ch #\() ; If code section, then use
(got-code (read port))) ; \verb;read; to get code,
(else ; else skip this line as it
(text-mode-within-a-line)))))) ; is a comment.
(text-mode-within-a-line
(lambda () ; Ignore comments.
(let ((ch (read-char port)))
(cond ((eof-object? ch) ch)
((char=? ch #\newline)
(text-mode-and-saw-newline))
(else (text-mode-within-a-line))))))
(got-code
(lambda (code) ; Ignore the remainder of the
(let ((ch (read-char port))) ; last code line and return
(cond ((eof-object? ch) code) ; the results of \verb;read;.
((char=? ch #\newline)
code)
(else (got-code code)))))))
(text-mode-and-saw-newline) ; Start by looking
))) ; for a code line.
\end{document}
SHAR_EOF
fi # end of overwriting check
# End of shell archive
exit 0
------------------------------
End of Scheme Digest
********************
∂31-Oct-89 1120 @zurich.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu records; BABY-DOE; another vote
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 31 Oct 89 11:20:18 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA28607; Tue, 31 Oct 89 14:17:07 EST
Received: from skinner.cs.uoregon.edu ([128.223.4.13]) by zurich.ai.mit.edu; Tue, 31 Oct 89 14:12:04 est
Received: from spencer.cs.uoregon.edu by skinner.cs.uoregon.edu with SMTP
(5.59++/IDA-1.2.8) id AA01729; Tue, 31 Oct 89 11:17:29 PST
Received: by spencer.cs.uoregon.edu; Tue, 31 Oct 89 11:16:37 PST
Date: Tue, 31 Oct 89 11:16:37 PST
From: will@cs.uoregon.edu
Message-Id: <8910311916.AA16009@spencer.cs.uoregon.edu>
To: rrrs-authors@zurich.ai.mit.edu
Subject: records; BABY-DOE; another vote
Here is the third and, I dare to hope, final version of the proposal.
Will, does this look like consensus?
Pavel
Yes indeed. Thank you, Pavel. Presumably the record proposal will be
part of R5RS, but I wonder if anyone would mind if I made it an appendix
to R4RS, like the macro stuff. If no one objects, I will assume no one
objects.
For that matter, would anyone mind if BABY-DOE (by whatever name results
from the vote being conducted by John Ramsdell) were also in an appendix
to R4RS, assuming we can agree on the remaining semantic issue?
You say you've forgotten the semantic issue? (Lucky you.) The issue is
whether a "for-effect" continuation (created by script-C for a <command>;
see the formal syntax and semantics):
A. accepts any number of return values.
B. requires exactly zero or exactly one value.
C. requires exactly one return value.
D. requires exactly zero return values.
Semantics A is implied by the current formal semantics, and is in my
opinion the most useful semantics. Semantics B is a random compromise
between C and D. Semantics C, the semantics that I mistakenly
characterized as the consensus months ago, is the most conservative
semantics that is compatible with the status quo. Jinx observed that
Semantics D would be the most reasonable semantics if we were designing
a new language, but Semantics D isn't viable because of compatibility
problems.
Assuming that Semantics D is out of the question, the three remaining
semantics are consistent in the sense that, for example, someone who
wants to implement Semantics A or B would be free to do so if
Semantics C were adopted. I therefore interpret a vote against
semantics C as a vote against A and B, and so on.
For the purpose of determining whether anyone objects to describing
BABY-DOE in an appendix to R4RS, for the purpose of knowing what
semantics to describe in the event that no one objects, and in any
case for the purpose of generating a semantics to accompany the agenda
item being generated by John Ramsdell's vote on the name, I would like
to conduct two votes. Please indicate your votes by putting your mark
in two of the boxes in the Vote column and mail your response directly
to me at will@cs.uoregon.edu. I will report the results at the end of
November by sending mail to this list.
----------------------------------------------------------------------
Vote | Position
======================================================================
|
| I do not object to describing BABY-DOE in an appendix to
| R4RS, provided its semantics is compatible with the semantics
| I favor.
----------------------------------------------------------------------
|
| I object to describing BABY-DOE in an appendix to R4RS.
|
|
======================================================================
|
| I do not object to semantics A: "for-effect" continuations
| accept any number of return values.
|
----------------------------------------------------------------------
|
| I object to semantics A but I do not object to semantics B:
| "for-effect" continuations accept either zero or one return
| value.
----------------------------------------------------------------------
|
| I object to semantics A and B but I do not object to
| semantics C: "for-effect" continuations accept one return
| value.
----------------------------------------------------------------------
|
| None of the above. Either I object to BABY-DOE, or I object
| to Clinger's stupid characterization of the alternative
| semantics for BABY-DOE.
======================================================================
∂31-Oct-89 1431 @zurich.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu inexact numbers in R3.99RS
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 31 Oct 89 14:31:33 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA02500; Tue, 31 Oct 89 17:26:51 EST
Received: from skinner.cs.uoregon.edu ([128.223.4.13]) by zurich.ai.mit.edu; Tue, 31 Oct 89 17:21:52 est
Received: from spencer.cs.uoregon.edu by skinner.cs.uoregon.edu with SMTP
(5.59++/IDA-1.2.8) id AA08285; Tue, 31 Oct 89 14:27:27 PST
Received: by spencer.cs.uoregon.edu; Tue, 31 Oct 89 14:26:39 PST
Date: Tue, 31 Oct 89 14:26:39 PST
From: will@cs.uoregon.edu
Message-Id: <8910312226.AA17572@spencer.cs.uoregon.edu>
To: rrrs-authors@zurich.ai.mit.edu
Subject: inexact numbers in R3.99RS
I want to point out and explain a few changes that were made in R3.99RS
that have to do with inexact numbers. First of all, I added an explicit
note to the description of MAX and MIN. Secondly, I relaxed the
specification of NUMBER->STRING to allow for implementations that
don't necessarily use floating point to represent inexact numbers.
Thirdly, I followed a suggestion made by the P1178 editors in making
part of the behavior of STRING->NUMBER optional to take into account
the fact that all numbers other than exact integers are optional.
Here are the relevant excerpts from the LaTeX for R3.99RS. You don't
need to tell me about the place where I used "an" when I should have
used "a".
\begin{entry}{%
\proto{max}{ \vri{x} \vrii{x} \dotsfoo}{essential procedure}
\proto{min}{ \vri{x} \vrii{x} \dotsfoo}{essential procedure}}
These procedures return the maximum or minimum of their arguments.
\begin{scheme}
(max 3 4) \ev 4 ; exact
(max 3.9 4) \ev 4.0 ; inexact%
\end{scheme}
\begin{note}
If any argument is inexact, then the result will also be inexact (unless
the procedure can prove that the inaccuracy is not large enough to affect the
result, which is possible only in unusual implementations). If \ide{min} or
\ide{max} is used to compare numbers of mixed exactness, and the numerical
value of the result cannot be represented as an inexact number without loss of
accuracy, then the procedure may report a violation of an implementation
restriction.
\end{note}
\end{entry}
\begin{entry}{%
\proto{number->string}{ number}{essential procedure}
\proto{number->string}{ number radix}{essential procedure}}
\vr{Radix} must be an exact integer, either 2, 8, 10, or 16. If omitted,
\vr{radix} defaults to 10.
The procedure \ide{number\coerce{}string} takes a
number and a radix and returns as a string an external representation of
the given number in the given radix such that
\begin{scheme}
(let ((number \vr{number})
(radix \vr{radix}))
(eqv? number
(string->number (number->string number
radix)
radix)))
\end{scheme}
is true. It is an error if no possible result makes this expression true.
If \vr{number} is inexact, the radix is 10, and the above expression
can be satisfied by a result that contains a decimal point,
then the result contains a decimal point and is expressed using the
minimum number of digits (exclusive of exponent and trailing
zeroes) needed to make the above expression true~\cite{Heuristic};
otherwise the format of the result is unspecified.
The result returned by \ide{number\coerce{}string}
never contains an explicit radix prefix.
\begin{note}
The error case can occur only when \vr{number} is not a complex number
or is a complex number with an non-rational real or imaginary part.
\end{note}
\begin{rationale}
If \vr{number} is an inexact number represented using flonums, and
the radix is 10, then the above expression is normally satisfied by
a result containing a decimal point. The unspecified case
allows for infinities, NaNs, and non-flonum representations.
\end{rationale}
\end{entry}
\begin{entry}{%
\proto{string->number}{ string}{essential procedure}
\proto{string->number}{ string radix}{essential procedure}}
%%R4%% I didn't include the (string->number string radix exactness)
% case, since I haven't heard any resolution of the coding to be used
% for the third argument.
Returns a number of the maximally precise representation expressed by the
given \vr{string}. \vr{Radix} must be an exact integer, either 2, 8, 10,
or 16. If supplied, \vr{radix} is a default radix that may be overridden
by an explicit radix prefix in \vr{string} (e.g. {\tt "\#o177"}). If \vr{radix}
is not supplied, then the default radix is 10. If \vr{string} is not
a syntactically valid notation for a number, then \ide{string->number}
returns \schfalse{}.
\begin{scheme}
(string->number "100") \ev 100
(string->number "100" 16) \ev 256
(string->number "1e2") \ev 100.0
(string->number "15\#\#") \ev 1500.0%
\end{scheme}
\begin{note}
Although \ide{string->number} is an essential procedure,
an implementation may restrict its domain in the
following ways. \ide{String->number} is permitted to return
\schfalse{} whenever \vr{string} contains an explicit radix prefix.
If all numbers supported by an implementation are real, then
\ide{string->number} is permitted to return \schfalse{} whenever
\vr{string} uses the polar or rectangular notations for complex
numbers. If all numbers are integers, then
\ide{string->number} may return \schfalse{} whenever
the fractional notation is used. If all numbers are exact, then
\ide{string->number} may return \schfalse{} whenever
an exponent marker or explicit exactness prefix is used, or if
a {\tt \#} appears in place of a digit. If all inexact
numbers are integers, then
\ide{string->number} may return \schfalse{} whenever
a decimal point is used.
\end{note}
\end{entry}
∂01-Nov-89 2216 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #236
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Nov 89 22:15:56 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA26582; Thu, 2 Nov 89 01:14:28 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Thu, 2 Nov 89 01:09:00 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa00469;
2 Nov 89 0:58 EST
Date: 2 NOV 89 00:11:50 EST
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.lcs.mit.edu>
Subject: Scheme Digest #236
To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Message-Id: <8911020058.aa00469@mintaka.lcs.mit.edu>
Scheme Digest #236 2 NOV 89 00:11:50 EST
Today's Topics:
Elk on SUN4
Elk on SUN4
CFP: Workshop PLILP 90
sub
sub
----------------------------------------------------------------------
Date: 1 Nov 89 11:03:46 GMT
From: Jeffrey Putnam <snorkelwacker!usc!zaphod.mps.ohio-state.edu!rpi!jefu@eddie.mit.edu>
Subject: Re: Elk on SUN4
Message-Id: <1989Nov1.110346.13013@rpi.edu>
Has anyone tried porting ELK to DOS (ick)? I've tried compiling the
C files and they seem to compile ok, but I have no idea what to do with
the assembler. Anyone out there who actually likes these chips and their
machine language that has fiddled them?
I know, even compiling may not be enough - then you need to fit it into
memory, but it would be interesting to at least compile it and try.
BTW I tried compiling the recently announced fools lisp in Turbo C. It
refused absolutely to compile because of C macros like
#define xx(a,b,c) {a,b,c}
#define yy(a,b,c} {a,b,c}
xx(yy(1,2,3),4,5)
--
jeff putnam -- I should have been a pair of ragged claws
jefu@pawl.rpi.edu -- Scuttling across the floors of silent seas.
/* One semester to Phinish! (I hope) */
------------------------------
Date: 1 Nov 89 07:46:44 GMT
From: Don Hopkins <brillig.umd.edu!don@mimsy.umd.edu>
Subject: Re: Elk on SUN4
Message-Id: <20484@mimsy.umd.edu>
Patches for ELK on the SPARC.
This was my first sparc program, so it could be stupid in places, but it
seems to work. Any and all bugs are my fault, and anything that works is
due to help from from Mark Weiser, John Gilmore, and Mitch Bradley's
kick-ass Sun-4 Forth system.
Some times it seems to try to allocate huge amounts of memory, and runs
out of stack space. I haven't tracked this bug down yet, but please let me
know if you do.
-Don Hopkins (don@brillig.umd.edu)
* Changed files:
** Makefile:
Put the following definitions in the top level Makefile.
I changed the GENERIC and the SCHEME_DIR definitions to do the quoting
differently, because it was confusing the SunOS 3.2 compiler.
SCHEME_DIR= /f/net/scm/scm
GENERIC= char *
MACHTYPE= sparc # vax 68k 386 sparc
DIR= -DDEF_LOAD_DIR=\\\"$(SCHEME_DIR)\\\"
GEN= -DGENERIC=\"$(GENERIC)\"
CFLAGS= $(INC) $(DIR) $(GEN) -O4 # SunOS 4.0
LDFLAGS= -x # 4.n BSD
** src/config.h:
Right before the end of the #ifdef sun section, add the following:
# ifdef sparc
/* This is outside of this .h file cause the sun 3 3.2 preprocesser
barfs on pragma, even if it's ifdef'ed out. */
# include "sparc.h"
# endif
I found I had to change the heap size to get the test programs to work
(I doubled it from 512 to 1024):
#define HEAP_SIZE 1024 /* in KBytes */
* New files:
** src/sparc.h:
Required because SunOS 3.2 cpp barfs on "#pragma". Enclosed.
** src/stack.s.sparc:
Implements stack manipulation code on sparc. Enclosed.
** src/alloca.s.sparc:
Just an empty file. (Not enclosed. Buy me a beer, and I'll be
happy to supply you with a uuencoded compressed tar file with a
hand-made empty file that will work very well for this purpose.)
* Instructions:
Apply the changes to "Makefile" and "src/config.h".
Put the files "src/sparc.h" and "src/stack.s.sparc" in place.
Make an empty file, "src/alloca.s.sparc" (unless you'd rather buy me a beer).
Type "make" in the top level directory.
* Files:
** src/sparc.h
#include <alloca.h>
extern int saveenv(), jmpenv();
#pragma unknown_control_flow(saveenv,jmpenv)
** src/stack.s.sparc
/* int stksize();
*/
.globl _stksize
.globl _Special
_stksize:
set _stkbase,%o1
ld [%o1],%o1
mov %sp,%o0
sub %o1,%o0,%o0
retl
add %o0,256,%o0
/* int saveenv(char* envbuf);
*/
.globl _saveenv
_saveenv:
save %sp,-96,%sp /* new window */
/* i0: char *envbuf */
t 0x3 /* ST_FLUSH_WINDOWS trap */
st %i7,[%i0+4] /* saved PC */
mov %y,%l0
st %l0,[%i0+8] /* Y register */
#ifdef notdef
/* Illegal instruction. This doesn't seem to be necessary... */
mov %psr,%l0
st %l0,[%i0+12] /* PSR register */
#endif
st %sp,[%i0+16] /* SP register */
st %fp,[%i0+20] /* FP register */
st %g1,[%i0+40] /* save globals */
st %g2,[%i0+44]
st %g3,[%i0+48]
st %g4,[%i0+52]
st %g5,[%i0+56]
st %g6,[%i0+60]
st %g7,[%i0+64]
mov %sp,%l0 /* %l0 source */
add %i0,128,%l1 /* %l1 dest */
set _stkbase,%l2 /* %l2 limit */
ld [%l2],%l2
rep1: /* copy stack to buf */
ld [%l0],%l3
st %l3,[%l1]
inc 4,%l1
cmp %l0,%l2
bleu rep1
inc 4,%l0
sub %l1,%l0,%l1 /* %l1 relocation offset */
st %l1,[%i0] /* store at front of buffer */
set _Special,%i0 /* return value */
ld [%i0],%i0
ret
restore
/* dead jmpenv(const char* envbuf, int retcode);
*/
.globl _jmpenv
_jmpenv:
save %sp,-96,%sp /* new window */
/* i0: char *envbuf */
/* i1: int retcode */
t 0x3 /* ST_FLUSH_WINDOWS trap */
ld [%i0+16],%l1 /* l1: SP register */
mov %l1,%sp
add %i0,128,%l0 /* %l0: source */
/* %l1: dest */
set _stkbase,%l2 /* %l2: limit */
ld [%l2],%l2
rep2: /* copy buf to stack */
ld [%l0],%l3
st %l3,[%l1]
inc 4,%l1
cmp %l1,%l2
bleu rep2
inc 4,%l0
ld [%i0+40],%g1
ld [%i0+44],%g2
ld [%i0+48],%g3
ld [%i0+52],%g4
ld [%i0+56],%g5
ld [%i0+60],%g6
ld [%i0+64],%g6
ld [%i0+20],%fp
#ifdef notdef
ld [%i0+12],%l0
/* Illegal instruction. This doesn't seem to be necessary... */
mov %l0,%psr
#endif
ld [%i0+8],%l0
mov %l0,%y
ld [%i0+4],%i7
nop /* ??? */
mov %i1,%i0
ret
restore
------------------------------
Date: 1 Nov 89 11:59:06 GMT
From: Torbjorn Naslund <eru!luth!sunic!liuida!torna@bloom-beacon.mit.edu>
Subject: CFP: Workshop PLILP 90
Message-Id: <1415@majestix.ida.liu.se>
CALL FOR PAPERS
Workshop on
Programming Language Implementation
and
Logic Programming
20-22 August 1990 - Linkoping, Sweden
The aim of the workshop is to explore new concepts, methods and
techniques relevant for implementation of all kinds of programming
languages, whether algorithmic or declarative. The intention is to bring
together researchers from the fields of algorithmic programming
languages, logic programming, functional programming and object-oriented
programming. The topics include, but are not restricted to:
- static analysis
- code generation
- executable specification, implementation of declarative
concepts
- compiler specification and construction
- program transformation
- programming environments
- amalgamation of algorithmic, functional, object-oriented and
logic programming
Program Committee
M. Bruynooghe, Katholieke Univ., Leuven, Belgium
S. Debray, Univ. of Arizona, Tucson, USA
P. Deransart, INRIA, Rocquencourt, France (program chairman)
P. Franchi Zannettacci, Univ. of Nice, France
H. Ganzinger, Univ. of Dortmund, FRG
S. Haridi, SICS, Stockholm, Sweden
N.D. Jones, Univ. of Copenhagen, Denmark
F. Kluzniak, Univ. of Bristol, UK/Univ. of Warsaw, Poland
V. Kotov, Academy of Science, Novosibirsk, USSR
B. Lang, INRIA, Rocquencourt, France
G. Levi, Univ. of Pisa, Italy
G. Lindstrom, Univ. of Utah, Salt Lake City, USA
J. Maluszynski, Linkoping Univ., Sweden (program co-chairman)
J. Penjam, Academy of Science, Tallin, USSR
M. Sassa, Univ. of Tsukuba, Japan
P. Szeredi, Univ. of Bristol, UK/Univ. of Budapest, Hungary
M. Wirsing, Univ. of Passau, FRG
Papers must be written and presented in English and must not exceed 5000
words. Submit five copies of the manuscript by 1 April 1990 to
Torbjorn Naslund - PLILP 90
Dept. of Computer and Information Science
Linkoping University
S-581 83 Linkoping
Sweden
If possible the submission should be accompanied by a 100 word abstract
sent by e-mail to plilp@ida.liu.se. Authors will be notified of
acceptance/rejection by 1 June 1990 by e-mail (if available).
Camera-ready copy will be due 30 June 1990.
------------------------------
Date: Wed, 1 Nov 89 20:01:39 EST
From: "Yong Su Kim"@cunixb.cc.columbia.edu
Reply-To: Yong Su Kim <yk4@cunixb.cc.columbia.edu>
Subject: sub
Message-Id: <CMM.0.88.625971699.yk4@cunixb.cc.columbia.edu>
sub
_____________________________________________________________________________
|Internet: yk4@cunixb.cc.columbia.edu |||||||The Korean from Hong Kong.||||||
|Bitnet : yk4@cunixc |||||||||||||||||||||||||||||||||||||||
|UUCP : rutgers!columbia!cunixc!yk4 ||||||||||...Apple IIGS user...||||||||
|_______________________________________|||||||||||||||||||||||||||||||||||||||
------------------------------
Date: 2 Nov 89 01:01:39 GMT
From: CUNIXB.CC.COLUMBIA.EDU!
Subject: sub
Message-Id: <CMM.0.88.625971699.yk4@cunixb.cc.columbia.edu>
sub
_____________________________________________________________________________
|Internet: yk4@cunixb.cc.columbia.edu |||||||The Korean from Hong Kong.||||||
|Bitnet : yk4@cunixc |||||||||||||||||||||||||||||||||||||||
|UUCP : rutgers!columbia!cunixc!yk4 ||||||||||...Apple IIGS user...||||||||
|_______________________________________|||||||||||||||||||||||||||||||||||||||
------------------------------
End of Scheme Digest
********************
∂02-Nov-89 1507 hal@zurich.ai.mit.edu another dumb question about numbers
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 2 Nov 89 15:07:50 PST
Received: from zurich.ai.mit.edu ([18.43.0.179]) by life.ai.mit.edu (4.0/AI-4.10) id AA08629; Thu, 2 Nov 89 18:02:52 EST
Received: from localhost by zurich.ai.mit.edu; Thu, 2 Nov 89 17:57:49 est
Date: Thu, 2 Nov 89 17:57:49 est
From: hal@zurich.ai.mit.edu (Hal Abelson)
Message-Id: <8911022257.AA13507@zurich.ai.mit.edu>
To: rrrs-authors@zurich.ai.mit.edu
Subject: another dumb question about numbers
Reply-To: hal@zurich.ai.mit.edu
Why not have round, floor, ceiling, and truncate produce exact
integers, and provide some other names for the analogous (more
primitive?) operations that do not force exactness?
∂02-Nov-89 1753 bawden@arisia.xerox.com another dumb question about numbers
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 2 Nov 89 17:52:53 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA10686; Thu, 2 Nov 89 20:50:47 EST
Received: from arisia.Xerox.COM (arisia.xerox.com) by zurich.ai.mit.edu; Thu, 2 Nov 89 20:45:54 est
Received: from roo.parc.Xerox.COM by arisia.Xerox.COM with SMTP
(5.61+/IDA-1.2.8/gandalf) id AA26357; Thu, 2 Nov 89 17:47:30 -0800
Received: from mr-bun.parc.Xerox.COM by roo.parc.xerox.com with SMTP
(5.61+/IDA-1.2.8/gandalf) id AA00680; Thu, 2 Nov 89 17:49:01 PST
Date: Thu, 2 Nov 89 17:46 PST
From: Alan Bawden <bawden@parc.xerox.com>
Subject: another dumb question about numbers
To: hal@zurich.ai.mit.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: <8911022257.AA13507@zurich.ai.mit.edu>
Message-Id: <19891103014626.4.ALAN@MR-BUN.parc.xerox.com>
Date: Thu, 2 Nov 89 17:57:49 est
From: Hal Abelson <hal@zurich.ai.mit.edu>
Why not have round, floor, ceiling, and truncate produce exact
integers, and provide some other names for the analogous (more
primitive?) operations that do not force exactness?
Suppose you were porting your program from a Scheme that supported exact
rationals to a scheme that only supported exact integers. Suppose that in
the case where (/ P Q) is not an integer the latter Scheme implementation
returned an inexact number (perhaps represented using floating-point).
Then if FLOOR did a silent coercion, (FLOOR (/ P Q)), where P and Q are
exact integers in both implementations, might return different exact
integers as answers -- the correct answer in the first Scheme, and an
incorrect answer in the second. Again the "silent coercion" has silently
introduced a potential bug. If you -expected- an inexact quotient, then
you probably should have written (INEXACT->EXACT (FLOOR (/ P Q))).
I think we already had an analogous discussion about MAX and MIN.
∂03-Nov-89 0647 @zurich.ai.mit.edu,@mc.lcs.mit.edu:hieb@iuvax.cs.indiana.edu floor & inexact->exact
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 3 Nov 89 06:47:18 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA17992; Fri, 3 Nov 89 09:41:14 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Fri, 3 Nov 89 09:36:23 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa11003;
3 Nov 89 9:36 EST
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 3 Nov 89 09:35:44 EST
Received: from iuvax.cs.indiana.edu by mintaka.lcs.mit.edu id aa10930;
3 Nov 89 9:31 EST
Received: by iuvax.cs.indiana.edu
Date: Fri, 3 Nov 89 09:31:26 -0500
From: Robert Hieb <hieb@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: floor & inexact->exact
Message-Id: <8911030931.aa10930@mintaka.lcs.mit.edu>
Date: Thu Nov 2 20:52:46 1989
From: Alan Bawden <bawden@parc.xerox.com>
Subject: another dumb question about numbers
Date: Thu, 2 Nov 89 17:57:49 est
From: Hal Abelson <hal@zurich.ai.mit.edu>
Why not have round, floor, ceiling, and truncate produce exact
integers, and provide some other names for the analogous (more
primitive?) operations that do not force exactness?
...If you -expected- an inexact quotient, then
you probably should have written (INEXACT->EXACT (FLOOR (/ P Q))).
Probably not. I don't see how one can be sure that inexact->exact will
return an integer. To be sure one must write (floor (inexact->exact (/ p q))).
∂03-Nov-89 1526 bawden@arisia.xerox.com floor & inexact->exact
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 3 Nov 89 15:25:56 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA25722; Fri, 3 Nov 89 18:22:29 EST
Received: from arisia.Xerox.COM (arisia.xerox.com) by zurich.ai.mit.edu; Fri, 3 Nov 89 18:17:33 est
Received: from roo.parc.Xerox.COM by arisia.Xerox.COM with SMTP
(5.61+/IDA-1.2.8/gandalf) id AA29993; Fri, 3 Nov 89 15:19:02 -0800
Received: from mr-bun.parc.Xerox.COM by roo.parc.xerox.com with SMTP
(5.61+/IDA-1.2.8/gandalf) id AA00468; Fri, 3 Nov 89 15:20:31 PST
Date: Fri, 3 Nov 89 15:17 PST
From: Alan Bawden <bawden@parc.xerox.com>
Subject: floor & inexact->exact
To: hieb@iuvax.cs.indiana.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: <8911030931.aa10930@mintaka.lcs.mit.edu>
Message-Id: <19891103231752.5.ALAN@MR-BUN.parc.xerox.com>
Date: Fri, 3 Nov 89 09:31:26 -0500
From: Robert Hieb <hieb@iuvax.cs.indiana.edu>
Date: Thu Nov 2 20:52:46 1989
From: Alan Bawden <bawden@parc.xerox.com>
...If you -expected- an inexact quotient, then you probably should
have written (INEXACT->EXACT (FLOOR (/ P Q))).
Probably not. I don't see how one can be sure that inexact->exact will
return an integer. To be sure one must write
(floor (inexact->exact (/ p q))).
Recall that I was postulating a Scheme implementation without exact
rationals, only exact integers. (INEXACT->EXACT (/ 5 3)) could plausibly
return and exact 1 or an exact 2 in such an implementation, or it might
signal an error, but it -can't- return an exact 5/3. Thus
(FLOOR (INEXACT->EXACT (/ 5 3)))
might return (in that implementation) either an exact 1 or an exact 2 or it
might signal an error. The latter two outcomes are probably not what was
expected.
So, if you -knew- that INEXACT->EXACT always rounded down in that Scheme
implementation, then you could indeed write (FLOOR (INEXACT->EXACT (/ P Q))).
(But note that this won't help you if you want to compute (ROUND (/ P Q)).)
If, on the other hand, you knew that the Scheme implementation in question
used floating point for its inexact numbers, then:
(/ 5 3) => 1.6666666
(FLOOR (/ 5 3)) => 1.0
(INEXACT->EXACT (FLOOR (/ 5 3))) => 1
This works because floating point happens to have a representation for
-every- integer that might result from calling FLOOR, CEILING, TRUNCATE or
ROUND on another floating point number.
Now it seems to -me- to be more likely that you are porting your program to
a Scheme that uses floating point than to a Scheme who's INEXACT->EXACT is
guaranteed to always round down. So -I- would write
(INEXACT->EXACT (FLOOR (/ P Q))). If -you- want to bet the other way, that
is your choice. (Note that I originally said you only that you "-probably-
should have written ...".)
In fact, -neither- order is guaranteed to work in -all- Scheme
implementations because there aren't enough constraints on the behavior of
inexact numbers. INEXACT->EXACT is just like `<' in that you can't
usefully apply it to inexact arguments unless you know something more about
the inexact numbers you are using than is specified in the report.
∂03-Nov-89 1627 KMP@stony-brook.scrc.symbolics.com another dumb question about numbers
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 3 Nov 89 16:27:06 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA26435; Fri, 3 Nov 89 19:23:04 EST
Received: from life.ai.mit.edu (life.ai.mit.edu) by zurich.ai.mit.edu; Fri, 3 Nov 89 19:18:13 est
Received: from STONY-BROOK.SCRC.Symbolics.COM by life.ai.mit.edu (4.0/AI-4.10) id AA26431; Fri, 3 Nov 89 19:22:44 EST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 687261; 3 Nov 89 19:21:32 EST
Date: Fri, 3 Nov 89 19:21 EST
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Subject: another dumb question about numbers
To: hal@zurich.ai.mit.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: <8911022257.AA13507@zurich.ai.mit.edu>
Message-Id: <19891104002117.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Thu, 2 Nov 89 17:57:49 est
From: Hal Abelson <hal@zurich.ai.mit.edu>
Why not have round, floor, ceiling, and truncate produce exact
integers, and provide some other names for the analogous (more
primitive?) operations that do not force exactness?
This doesn't seem right. What if I ask
How far is it from Boston to San Francisco
and someone returns replies "About 3000 miles."
If I do (FLOOR 3000) to get an integer, that oughtn't make the
number exact. All it should gurantee me is that the result has
no fractional part (which in this case was also true of the input,
but only incidentally). It's a common thing for humans to not
specify a fractional part of something if the number is no good
in the ones-ies place, but there's no necessary reason. e.g.,
a number like 3.5 might really be 3.5+/-2.1 because of other errors
introduced in the computation. So to round that number and say that
it is an exact 3 or exact 4 neglects that an exact 2 or even an
exact 1 might be the right exact answer if all the accumulated error was
in that direction.
∂03-Nov-89 2121 @zurich.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu Re: floor & inexact->exact
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 3 Nov 89 21:21:47 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA29794; Sat, 4 Nov 89 00:17:03 EST
Received: from skinner.cs.uoregon.edu ([128.223.4.13]) by zurich.ai.mit.edu; Sat, 4 Nov 89 00:10:30 est
Received: from spencer.cs.uoregon.edu by skinner.cs.uoregon.edu with SMTP
(5.59++/IDA-1.2.8) id AA13022; Fri, 3 Nov 89 21:14:55 PST
Received: by spencer.cs.uoregon.edu; Fri, 3 Nov 89 21:14:04 PST
Date: Fri, 3 Nov 89 21:14:04 PST
From: will@cs.uoregon.edu
Message-Id: <8911040514.AA12234@spencer.cs.uoregon.edu>
To: bawden@parc.xerox.com, hieb@iuvax.cs.indiana.edu
Subject: Re: floor & inexact->exact
Cc: rrrs-authors@zurich.ai.mit.edu
From: Alan Bawden <bawden@parc.xerox.com>
...If you -expected- an inexact quotient, then
you probably should have written (INEXACT->EXACT (FLOOR (/ P Q))).
From: Robert Hieb <hieb@iuvax.cs.indiana.edu>
Probably not. I don't see how one can be sure that inexact->exact will
return an integer. To be sure one must write
(floor (inexact->exact (/ p q))).
Although FLOOR is guaranteed to return an integer, you can't be sure
that it will return an exact integer unless its argument is an exact
integer within the (constrained but nonetheless implementation-dependent)
range of exact integers. There is also an implementation-dependent
range within which INEXACT->EXACT is guaranteed to implement "the natural
one-to-one correspondence between inexact and exact integers". If you
know that (/ P Q) is in that latter range, then
(INEXACT->EXACT (FLOOR (/ P Q))) [1]
is guaranteed to return an exact integer. If you know that (/ P Q) is in
the former range, then
(FLOOR (INEXACT->EXACT (/ P Q))) [2]
is guaranteed to return an exact integer. So the expression to use depends
on what you know about your implementation, what you know about (/ P Q),
and perhaps, in situations where you might not know these things, whether
[1] you'd prefer to have an exact number that might not be an integer or
[2] an integer that might not be exact.
In most implementations, the range within which INEXACT->EXACT reliably
maps inexact integers to exact integers is the same as the range in which
FLOOR is guaranteed to return an exact integer. Expression [1], however,
is less likely to violate an implementation restriction, because
INEXACT->EXACT might barf in a typical fixnum/flonum implementation if
its argument isn't an integer. That's why I recommend [1] over [2].
As Alan Bawden explained, you might also choose [1] because you want
the FLOOR instead of the CEILING, but if this matters greatly to you
then perhaps you should consider writing code that reports an error
whenever (/ P Q) is inexact.
Peace, Will
∂03-Nov-89 2158 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #237
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 3 Nov 89 21:58:44 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA29986; Sat, 4 Nov 89 00:57:56 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Sat, 4 Nov 89 00:53:01 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa20555;
4 Nov 89 0:31 EST
Date: 4 NOV 89 00:12:32 EST
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.lcs.mit.edu>
Subject: Scheme Digest #237
To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Message-Id: <8911040031.aa20555@mintaka.lcs.mit.edu>
Scheme Digest #237 4 NOV 89 00:12:32 EST
Today's Topics:
Personal to Blake McNeill (email seems flakey)
----------------------------------------------------------------------
Date: 3 Nov 89 15:45:23 GMT
From: Roommate of Lord Greystoke <uwslh!lishka@speedy.wisc.edu>
Subject: Personal to Blake McNeill (email seems flakey)
Message-Id: <454@uwslh.UUCP>
I apologize to the rest of the net for doing this, but my email
connection to Blake seems kind of flakey.
Blake, I sent you an email letter several days ago to make sure
that the path from me to you was OK. I have not received a reply yet,
which seems kind of strange (although it is possible that a mailer in
between us is playing around with the letter for awhile). Please send
me email indicating whether or not you got my reply. I do not want to
send out large files without a reliable path. Also, if you have ftp
capabilities, we might me able to work something out with ftp over the
network (much faster).
.oO Chris Oo.
--
Christopher Lishka ...!{rutgers|ucbvax|...}!uwvax!uwslh!lishka
Wisconsin State Lab of Hygiene lishka%uwslh.uucp@cs.wisc.edu
Data Processing Section (608)262-4485 lishka@uwslh.uucp
"What a waste it is to lose one's mind -- or not to have a mind at all.
How true that is." -- V.P. Dan Quayle, garbling the United Negro College
Fund slogan in an address to the group (from Newsweek, May 22nd, 1989)
------------------------------
End of Scheme Digest
********************
∂06-Nov-89 0913 @zurich.ai.mit.edu,@RELAY.CS.NET,@tektronix.tek.com:kend@mrloog.wr.tek.com Re: records; BABY-DOE; another vote
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 6 Nov 89 09:13:35 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA25765; Mon, 6 Nov 89 12:06:29 EST
Received: from RELAY.CS.NET (relay.cs.net) by zurich.ai.mit.edu; Mon, 6 Nov 89 12:01:40 est
Received: from tektronix.tek.com by RELAY.CS.NET id aa06496; 6 Nov 89 11:06 EST
Received: by tektronix.TEK.COM (5.51/7.1)
id AA07570; Mon, 6 Nov 89 09:06:17 PST
Received: by wrgate.wr.tek.com (5.51/7.1)
id AA08819; Mon, 6 Nov 89 09:05:11 PST
Received: by mrloog.WR.TEK.COM (1.2/7.1)
id AA13200; Mon, 6 Nov 89 09:05:21 pst
Message-Id: <8911061705.AA13200@mrloog.WR.TEK.COM>
To: will%cs.uoregon.edu@relay.cs.net
Cc: rrrs-authors@zurich.ai.mit.edu, kend@mrloog.wr
Subject: Re: records; BABY-DOE; another vote
In-Reply-To: Your message of Tue, 31 Oct 89 11:16:37 PST.
<8910311916.AA16009@spencer.cs.uoregon.edu>
Date: 06 Nov 89 09:05:09 PST (Mon)
From: kend%mrloog.wr.tek.com@relay.cs.net
----------------------------------------------------------------------
Vote | Position
======================================================================
/|
/ | I do not object to describing BABY-DOE in an appendix to
\ / | R4RS, provided its semantics is compatible with the semantics
\/ | I favor.
----------------------------------------------------------------------
|
| I object to describing BABY-DOE in an appendix to R4RS.
|
|
======================================================================
/|
/ | I do not object to semantics A: "for-effect" continuations
\ / | accept any number of return values.
\/ |
----------------------------------------------------------------------
|
| I object to semantics A but I do not object to semantics B:
| "for-effect" continuations accept either zero or one return
| value.
----------------------------------------------------------------------
|
| I object to semantics A and B but I do not object to
| semantics C: "for-effect" continuations accept one return
| value.
----------------------------------------------------------------------
|
| None of the above. Either I object to BABY-DOE, or I object
| to Clinger's stupid characterization of the alternative
| semantics for BABY-DOE.
======================================================================
[but then you knew that]
-Ken
P.S. look for a tape in the mail.
∂07-Nov-89 1239 @zurich.ai.mit.edu,@mc.lcs.mit.edu,@zermatt.lcs.mit.edu:ziggy@hx.lcs.mit.edu COND/DO consistency
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 7 Nov 89 12:38:54 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA14120; Tue, 7 Nov 89 15:34:12 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Tue, 7 Nov 89 15:29:22 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa05930;
7 Nov 89 15:12 EST
Received: from ZERMATT.LCS.MIT.EDU (CHAOS 17316) by MC.LCS.MIT.EDU 7 Nov 89 15:13:43 EST
Received: from HX.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via INTERNET with SMTP id 309764; 7 Nov 89 15:10:48 EST
Received: by hx.LCS.MIT.EDU (5.51/4.7); Tue, 7 Nov 89 15:07:18 EST
Date: Tue, 7 Nov 89 15:07:18 EST
From: "Michael R. Blair" <ziggy@hx.lcs.mit.edu>
Message-Id: <8911072007.AA17988@hx.LCS.MIT.EDU>
To: rrrs-authors@zermatt.lcs.mit.edu
Subject: COND/DO consistency
Consider: [paraphrase of 4.2.1]
| (COND (<test> <expression>...)
| (<test> <expression>...)
| ...
| (ELSE <expression> <expression>...))
|
| For the first <test> that evaluates to a true value, the value of
| the last <expression> in that clause is returned as the result of the
| COND. If that clause contains only a <test> and no <expression>s,
| then the value of the <test> is returned as the result.
Compare with: [paraphrase of 4.2.4]
| (DO ((<variable> <init> <step>)
| ...)
| (<test> <expression>...)
| <command>...)
|
| If the <test> evaluates to a true value, then the value of the last
| <expression> is returned as the result of the DO. If no <expression>s
| are present, then the value of the DO expression is unspecified.
I propose that this last line read "then the value of the <test> is
returned as the value of the DO expression." for consistency with the
way test clauses are handled in COND.
Consequently, I propose that the rewrite rule for DO in section 7.3
be changed to:
| (DO ((<variable_1> <init_1> <step_1>)
| ...)
| (<test> <expression>...) ;; NB: <sequence> changed to <expr>...
| <command_1>...)
|
| = (LETREC ((<loop>
| (LAMBDA (<variable_1>...)
| (COND (<test> <expression>...) ;; NB: COND
| (ELSE <command_1> ;; not IF
| ... ;;
| (<loop> <step_1>...)))))) ;;
| (<loop> <init_1>...))
This is a virtually effortless change which enhances the regularity
of the language.
~Ziggy
∂07-Nov-89 1401 @zurich.ai.mit.edu,@mc.lcs.mit.edu,@zermatt.lcs.mit.edu:mkatz@garlic.stanford.edu COND/DO consistency
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 7 Nov 89 14:01:10 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA15420; Tue, 7 Nov 89 16:54:53 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Tue, 7 Nov 89 16:34:44 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa06449;
7 Nov 89 16:00 EST
Received: from ZERMATT.LCS.MIT.EDU (CHAOS 17316) by MC.LCS.MIT.EDU 7 Nov 89 16:03:36 EST
Received: from garlic.Stanford.EDU (INTERNET|36.22.0.43) by ZERMATT.LCS.MIT.EDU via INTERNET with SMTP id 309776; 7 Nov 89 16:00:37 EST
Received: by garlic.Stanford.EDU (5.57/Ultrix3.0-C)
id AA02880; Tue, 7 Nov 89 12:54:37 PST
Date: Tue, 7 Nov 89 12:54:37 PST
From: Morris Katz <mkatz@garlic.stanford.edu>
Message-Id: <8911072054.AA02880@garlic.Stanford.EDU>
To: ziggy@hx.lcs.mit.edu
Cc: rrrs-authors@zermatt.lcs.mit.edu
In-Reply-To: "Michael R. Blair"'s message of Tue, 7 Nov 89 15:07:18 EST <8911072007.AA17988@hx.LCS.MIT.EDU>
Subject: COND/DO consistency
Date: Tue, 7 Nov 89 15:07:18 EST
From: "Michael R. Blair" <ziggy@hx.lcs.mit.edu>
| (DO ((<variable> <init> <step>)
| ...)
| (<test> <expression>...)
| <command>...)
|
| If the <test> evaluates to a true value, then the value of the last
| <expression> is returned as the result of the DO. If no <expression>s
| are present, then the value of the DO expression is unspecified.
I propose that this last line read "then the value of the <test> is
returned as the value of the DO expression." for consistency with the
way test clauses are handled in COND.
To really increase the regularity of DO and COND, DO would have to take a
series of test/expression sets. The syntax would then be
(DO ((<variable_1> <init_1> <step_1>)
...)
((<test1> <expression>...)
(<test2> <expression>...)
...
)
<command_1>...)
In this case I would be in strong support of regularizing the handling of the
test expression.
Unfortunately, such an incompatible change is not likely to gain much support
given that the old syntax is already firmly established in many peoples
programs.
-------------------------------------------------------------------------------
Morry Katz
katz@cs.stanford.edu
-------------------------------------------------------------------------------
∂07-Nov-89 2153 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #238
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 7 Nov 89 21:52:57 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA22947; Wed, 8 Nov 89 00:52:09 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Wed, 8 Nov 89 00:47:18 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa10000;
8 Nov 89 0:34 EST
Date: 8 NOV 89 00:13:41 EST
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.lcs.mit.edu>
Subject: Scheme Digest #238
To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Message-Id: <8911080034.aa10000@mintaka.lcs.mit.edu>
Scheme Digest #238 8 NOV 89 00:13:41 EST
Today's Topics:
xscheme, cons-stream, macros
WANTED: fools source
----------------------------------------------------------------------
Date: 7 Nov 89 10:28:57 GMT
From: eagle!ncastellano@bloom-beacon.mit.edu
Subject: Re: xscheme, cons-stream, macros
Message-Id: <3304@eagle.wesleyan.edu>
In article <3258@eagle.wesleyan.edu>, I write:
> I've run into a problem in XSCHEME...since cons-stream is defined as a macro,
> it cannot be passed to higher-order procedures. The solution I'm using at the
> moment is I added to my XSCHEME.INI right after the macro definition:
>
> (define cons-stream (lambda (a b) (cons-stream a b)))
>
> This seems to work, but there must be a better solution. Any ideas?
>
> thanks,
> nick
>
OK...I figured out why I can't do this. I'm new to this, pay me no mind...
nick
------------------------------
Date: 7 Nov 89 16:34:01 GMT
From: Zane Thomas <pilchuck!pacer!zane@uunet.uu.net>
Subject: WANTED: fools source
Message-Id: <249@pacer.UUCP>
Can anyone make the source for fools scheme available for uucp???
------------------------------
End of Scheme Digest
********************
∂08-Nov-89 2157 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #239
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 8 Nov 89 21:56:52 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA12201; Thu, 9 Nov 89 00:55:59 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Thu, 9 Nov 89 00:51:05 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa19921;
9 Nov 89 0:33 EST
Date: 9 NOV 89 00:13:46 EST
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.lcs.mit.edu>
Subject: Scheme Digest #239
To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Message-Id: <8911090033.aa19921@mintaka.lcs.mit.edu>
Scheme Digest #239 9 NOV 89 00:13:46 EST
Today's Topics:
Scheme to Commonlisp
----------------------------------------------------------------------
Subject: Scheme to Commonlisp
Date: Wed, 08 Nov 89 12:38:51 +0000
From: Simon Ross <S.Ross@cs.ucl.ac.uk>
Message-ID: <8911080749.aa12548@mintaka.lcs.mit.edu>
Does anyone have any advice or experience with converting a
program in Scheme to CommonLisp (in this case Texas Instruments
Scheme and Vax Commonlisp)? If there is some nifty program out
there that could do the job?
Any help appreciated - we have deadline of Nov 27th but
assistance after that date will be gratefully received.
Simon Ross
Department of Computer Science
University College London
London WC1E 6BT
JANET: sross@uk.ac.ucl.cs
ARPA : sross@cs.ucl.ac.uk
UUCP : ...ukc!ucl-cs!sross
UUCP : mcvax!ukc!ucl!cs!sross
BITNET/EARN: sross%uk.ac.ucl.cs@ukacrl.bitnet
------------------------------
End of Scheme Digest
********************
∂09-Nov-89 2150 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #240
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 9 Nov 89 21:50:50 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA00788; Fri, 10 Nov 89 00:49:56 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Fri, 10 Nov 89 00:48:39 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa29179;
10 Nov 89 0:29 EST
Date: 10 NOV 89 00:08:07 EST
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.lcs.mit.edu>
Subject: Scheme Digest #240
To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Message-Id: <8911100029.aa29179@mintaka.lcs.mit.edu>
Scheme Digest #240 10 NOV 89 00:08:07 EST
Today's Topics:
Jonathan Lee's email addr???
How to build xscheme for the mac
why eval is evil
----------------------------------------------------------------------
Date: 9 Nov 89 05:09:05 GMT
From: Dan McCabe <thorin!unc!mccabe@mcnc.org>
Subject: Jonathan Lee's email addr???
Message-Id: <10442@thorin.cs.unc.edu>
Sorry to waste net bandwidth, but could Jonathan Lee (or someone who knows it)
please send me his email address? I have some info for you.
Thanx in advance,
danm
mccabe@cs.unc.edu
------------------------------
Date: 9 Nov 89 00:01:13 GMT
From: Paul Puglia <cunixc!puglia@columbia.edu>
Subject: How to build xscheme for the mac
Message-Id: <2091@cunixc.cc.columbia.edu>
How does you build xscheme on a macintosh ? I have a copy of
the xscheme sources compiles fine on a unix machine, and works
great on a pc with turbo c. When I tried to compile it on a
friends mac II using his copy of lightspeed c. I have no luck.
Could someone please describe the procedure to compile this program, and
comment on if anything else is need to compile xscheme. I know that you
need some resource to compile xlisp on a mac. Do you need the same sort of
stuff for xscheme
Thanks in advance
Paul Puglia
Dept of Civil Engineering
Columbia University
------------------------------
Date: 9 Nov 89 23:43:42 GMT
From: "Andrew L. M. Shalit" <cambridge.apple.com!alms@bloom-beacon.mit.edu>
Subject: why eval is evil
Message-Id: <ALMS.89Nov9184342@brazil.cambridge.apple.com>
OK, we all know eval is evil (notice that I didn't cross-post to
comp.lang.lisp, where probably only about 90% of the people know
eval is evil).
I'm looking for a paper which explains *why* eval is evil, and explains
how things like closures and backquote and such can be used instead.
I'm trying to re-educate some Lisp programmers who were raised in
the 1970's (some on InterLisp) and think that
<the power of Lisp> = <the power of eval>
Has anyone ever taken the time to write this stuff down? Or is it
just 'general culture'?
Send responses to alms@cambridge.apple.com. I'll post a summary if
there's interest.
thanks!
-andrew
------------------------------
End of Scheme Digest
********************
∂11-Nov-89 1923 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #241
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 11 Nov 89 19:23:40 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA17697; Sat, 11 Nov 89 01:40:07 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Sat, 11 Nov 89 01:38:42 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa23954;
11 Nov 89 1:01 EST
Date: 11 NOV 89 00:08:09 EST
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.lcs.mit.edu>
Subject: Scheme Digest #241
To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Message-Id: <8911110101.aa23954@mintaka.lcs.mit.edu>
Scheme Digest #241 11 NOV 89 00:08:09 EST
Today's Topics:
Scheme to Commonlisp
Scheme to Commonlisp
better permute/unpermute
----------------------------------------------------------------------
Date: 10 Nov 89 16:13:18 GMT
From: Bruce Krulwich <mailrus!accuvax.nwu.edu!krulwich@ohio-state.arpa>
Subject: Re: Scheme to Commonlisp
Message-Id: <1563@accuvax.nwu.edu>
In article <8911080749.aa12548@mintaka.lcs.mit.edu>, S.Ross@CS (Simon Ross)
writes:
>Does anyone have any advice or experience with converting a
>program in Scheme to CommonLisp (in this case Texas Instruments
>Scheme and Vax Commonlisp)? If there is some nifty program out
>there that could do the job?
Over this past summer I wrote a program to translate T to CommonLISP
(unfortunately I had to make the switch). It was not complete, but had a
framework for defining translation methods that can be used to handle the
parts of T that I didn't need to do.
If anyone is interested I can look into making this package available via
anonymous FTP.
Bruce Krulwich
Institute for the Learning Sciences
krulwich@ils.nwu.edu
------------------------------
Date: 10 Nov 89 17:58:32 GMT
From: "Andrew L. M. Shalit" <cambridge.apple.com!alms@bloom-beacon.mit.edu>
Subject: Re: Scheme to Commonlisp
Message-Id: <ALMS.89Nov10125832@brazil.cambridge.apple.com>
In article <8911080749.aa12548@mintaka.lcs.mit.edu>, S.Ross@CS (Simon Ross)
writes:
>Does anyone have any advice or experience with converting a
>program in Scheme to CommonLisp (in this case Texas Instruments
>Scheme and Vax Commonlisp)? If there is some nifty program out
>there that could do the job?
You may want to look at Pseudoscheme by Jonathon Reese. It compiles
Scheme to Common Lisp, with the exception of upward continuations.
Unfortunately, I don't have an FTP address.
-andrew
------------------------------
Date: 11 Nov 89 04:15:55 GMT
From: Mikael Pettersson <eru!luth!sunic!liuida!mikpe@bloom-beacon.mit.edu>
Subject: better permute/unpermute
Message-Id: <1428@senilix.ida.liu.se>
I see that in the R3.99RS (draft of Aug. 31) the sematics for function
application still uses the old definition of |permute| and |unpermute|
as global functions with constant behaviour for any number N of arguments.
I think I may have a simple solution that more accurately models the
intended meaning of allowing the evaluation order to vary not only
based on the _number_ of arguments, but also on the argument expressions
themselves, the environment and the receiving expression continuation.
Let us define a function |order| as follows:
order : U -> K -> Exp* -> (Exp* -> Exp*)x(E* -> E*)
axiom : if <p,u>=order rho kappa E*,
then p is a permutation,
u is a permutation,
and p and u are each others inverses. (*)
(*) I'm a bit uneasy with this wording since there's a type conflict
there. However, the same conflict is in the R3.99RS soo...
The idea is to allow |order| to rearrange the arguments freely based on
all the information a compiler might want to use. Non-determinism at
run-time is ruled out however.
The equation for application can then be modified to read:
E[(E0 E*)] = lambda rho kappa .
(lambda<permute,unpermute>.
;; same body as before
)(order rho kappa <E0>&E*)
Is this an appropriate definition or have I missed something?
/Mike
--
Mikael Pettersson, Dept of Comp & Info Sci, University of Linkoping, Sweden
email: mpe@ida.liu.se or ...!{mcsun,munnari,uunet,unido,...}!sunic!liuida!mpe
------------------------------
End of Scheme Digest
********************
∂11-Nov-89 2241 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #242
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 11 Nov 89 22:40:54 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA28583; Sun, 12 Nov 89 01:37:19 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Sun, 12 Nov 89 01:35:39 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa21469;
12 Nov 89 1:10 EST
Date: 12 NOV 89 00:08:10 EST
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.lcs.mit.edu>
Subject: Scheme Digest #242
To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Message-Id: <8911120110.aa21469@mintaka.lcs.mit.edu>
Scheme Digest #242 12 NOV 89 00:08:10 EST
Today's Topics:
A-STAR in Scheme
How to build xscheme for the mac
----------------------------------------------------------------------
Date: 11 Nov 89 02:03:11 GMT
From: bywater!arnor!arnor.watson.ibm.com!yozzo@uunet.uu.net
Subject: A-STAR in Scheme
Message-Id: <1989Nov11.020311.5475@arnor.uucp>
A while ago I asked about an implementation of the
A-STAR algorithm in Scheme.
Well, after some work I figured in out.
So, if anyone is interested, just drop me a note
and I will send you what I have.
------------------------------------------------------------------------------
| Ralph E. Yozzo | DISCLAIMER: The opinions expressed |
| IBM Thomas J. Watson Research Ctr. | herein are the Authors. |
| Arpanet: yozzo@ibm.com | And are not necessarily those of his |
| | employer. |
| Bitnet: yozzo@yktvmx.bitnet \---------------------------------------|
| Home: ..!uunet!bywater!acheron!larouch!yozzo | Phone: (914) 945-3634 work |
| | Phone: (914) 564-4731 home |
------------------------------------------------------------------------------
------------------------------
Date: 11 Nov 89 18:55:05 GMT
From: Eric Johnson <datapg!com50!pai!erc@uunet.uu.net>
Subject: Re: How to build xscheme for the mac
Message-Id: <742@pai.UUCP>
In article <2091@cunixc.cc.columbia.edu>, puglia@cunixc.cc.columbia.edu (Paul Puglia) writes:
> How does you build xscheme on a macintosh ? I have a copy of
> the xscheme sources compiles fine on a unix machine, and works
> great on a pc with turbo c. When I tried to compile it on a
> friends mac II using his copy of lightspeed c. I have no luck.
> Could someone please describe the procedure to compile this program, and
> comment on if anything else is need to compile xscheme. I know that you
> need some resource to compile xlisp on a mac. Do you need the same sort of
> stuff for xscheme
> Thanks in advance
> Paul Puglia
> Dept of Civil Engineering
> Columbia University
Porting Xlisp/XScheme:
Awhile back, while I was taking an AI course, I was spending a lot of time
trekking to campus and using their LISP system. To avoid travel time (and
to work on LISP at any hour I wanted), I got into porting XLisp. In looking at
the code, I'd say XLisp and XScheme are two of the most portable C programs
I have ever seen. Now, I've spent most of my time on XLisp, so your
mileage may vary, but...
XLisp seems to place most Operating System (OS)-dependent features in
separate files, named dosstuff.c, osptrs.h, osdefs.h. On UNIX, the "stuff:
file is called unixstuf.c and on the Mac its called macstuff.c (all file
names are <= 8 chars for MS-DOS). The mac version also has a resource
compiler file (that is, a file you run through the resource compiler to
generate a resource file).
I assume (hope) XScheme is similiar. Below, I placed all my Mac-related
files from XLisp (2.0, I think). The XScheme stuff should be similiar.
I hope these help. (Note: I don't have the full sources around now, just
the Mac and UNIX-specific files.) (Note2: Two extra files, macfun.c and
macinit.c are below, its been so long that I'm not sure if these are extras
or necessary--Sorry.)
I'm placing these files here in hopes they can help you with your porting. I
do know that binary executable versions of XScheme are available on the
BIX bulletin board (Byte magazine Information eXchange)--see Byte mag
for details. Getting the binaries would solve all the Mac porting
problems in one fell swoop.
Anyway, hope this helps,
-Eric
======================== macfun.c =============================================
/* macfun.c - macintosh user interface functions for xlisp */
#include <Quickdraw.h>
#include <WindowMgr.h>
#include <MemoryMgr.h>
#include "xlisp.h"
/* external variables */
extern GrafPtr cwindow,gwindow;
/* forward declarations */
FORWARD LVAL do_0();
FORWARD LVAL do_1();
FORWARD LVAL do_2();
/* xptsize - set the command window point size */
LVAL xptsize()
{
LVAL val;
val = xlgafixnum();
xllastarg();
TextSize((int)getfixnum(val));
InvalRect(&cwindow->portRect);
SetupScreen();
return (NIL);
}
/* xhidepen - hide the pen */
LVAL xhidepen()
{
return (do_0('H'));
}
/* xshowpen - show the pen */
LVAL xshowpen()
{
return (do_0('S'));
}
/* xgetpen - get the pen position */
LVAL xgetpen()
{
LVAL val;
Point p;
xllastarg();
SetPort(gwindow);
GetPen(&p);
SetPort(cwindow);
xlsave1(val);
val = consa(NIL);
rplaca(val,cvfixnum((FIXTYPE)p.h));
rplacd(val,cvfixnum((FIXTYPE)p.v));
xlpop();
return (val);
}
/* xpenmode - set the pen mode */
LVAL xpenmode()
{
return (do_1('M'));
}
/* xpensize - set the pen size */
LVAL xpensize()
{
return (do_2('S'));
}
/* xpenpat - set the pen pattern */
LVAL xpenpat()
{
LVAL plist;
char pat[8],i;
plist = xlgalist();
xllastarg();
for (i = 0; i < 8 && consp(plist); ++i, plist = cdr(plist))
if (fixp(car(plist)))
pat[i] = getfixnum(car(plist));
SetPort(gwindow);
PenPat(pat);
SetPort(cwindow);
return (NIL);
}
/* xpennormal - set the pen to normal */
LVAL xpennormal()
{
xllastarg();
SetPort(gwindow);
PenNormal();
SetPort(cwindow);
return (NIL);
}
/* xmoveto - Move to a screen location */
LVAL xmoveto()
{
return (do_2('m'));
}
/* xmove - Move in a specified direction */
LVAL xmove()
{
return (do_2('M'));
}
/* xlineto - draw a Line to a screen location */
LVAL xlineto()
{
return (do_2('l'));
}
/* xline - draw a Line in a specified direction */
LVAL xline()
{
return (do_2('L'));
}
/* xshowgraphics - show the graphics window */
LVAL xshowgraphics()
{
xllastarg();
scrsplit(1);
return (NIL);
}
/* xhidegraphics - hide the graphics window */
LVAL xhidegraphics()
{
xllastarg();
scrsplit(0);
return (NIL);
}
/* xcleargraphics - clear the graphics window */
LVAL xcleargraphics()
{
xllastarg();
SetPort(gwindow);
EraseRect(&gwindow->portRect);
SetPort(cwindow);
return (NIL);
}
/* do_0 - Handle commands that require no arguments */
LOCAL LVAL do_0(fcn)
int fcn;
{
xllastarg();
SetPort(gwindow);
switch (fcn) {
case 'H': HidePen(); break;
case 'S': ShowPen(); break;
}
SetPort(cwindow);
return (NIL);
}
/* do_1 - Handle commands that require one integer argument */
LOCAL LVAL do_1(fcn)
int fcn;
{
int x;
x = getnumber();
xllastarg();
SetPort(gwindow);
switch (fcn) {
case 'M': PenMode(x); break;
}
SetPort(cwindow);
return (NIL);
}
/* do_2 - Handle commands that require two integer arguments */
LOCAL LVAL do_2(fcn)
int fcn;
{
int h,v;
h = getnumber();
v = getnumber();
xllastarg();
SetPort(gwindow);
switch (fcn) {
case 'l': LineTo(h,v); break;
case 'L': Line(h,v); break;
case 'm': MoveTo(h,v); break;
case 'M': Move(h,v); break;
case 'S': PenSize(h,v);break;
}
SetPort(cwindow);
return (NIL);
}
/* getnumber - get an integer parameter */
LOCAL int getnumber()
{
LVAL num;
num = xlgafixnum();
return ((int)getfixnum(num));
}
/* xtool - call the toolbox */
LVAL xtool()
{
LVAL val;
int trap;
trap = getnumber();
/*
asm {
move.l args(A6),D0
beq L2
L1: move.l D0,A0
move.l 2(A0),A1
move.w 4(A1),-(A7)
move.l 6(A0),D0
bne L1
L2: lea L3,A0
move.w trap(A6),(A0)
L3: dc.w 0xA000
clr.l val(A6)
}
*/
return (val);
}
/* xtool16 - call the toolbox with a 16 bit result */
LVAL xtool16()
{
int trap,val;
trap = getnumber();
/*
asm {
clr.w -(A7)
move.l args(A6),D0
beq L2
L1: move.l D0,A0
move.l 2(A0),A1
move.w 4(A1),-(A7)
move.l 6(A0),D0
bne L1
L2: lea L3,A0
move.w trap(A6),(A0)
L3: dc.w 0xA000
move.w (A7)+,val(A6)
}
*/
return (cvfixnum((FIXTYPE)val));
}
/* xtool32 - call the toolbox with a 32 bit result */
LVAL xtool32()
{
int trap;
long val;
trap = getnumber();
/*
asm {
clr.l -(A7)
move.l args(A6),D0
beq L2
L1: move.l D0,A0
move.l 2(A0),A1
move.w 4(A1),-(A7)
move.l 6(A0),D0
bne L1
L2: lea L3,A0
move.w trap(A6),(A0)
L3: dc.w 0xA000
move.l (A7)+,val(A6)
}
*/
return (cvfixnum((FIXTYPE)val));
}
/* xnewhandle - allocate a new handle */
LVAL xnewhandle()
{
LVAL num;
long size;
num = xlgafixnum(); size = getfixnum(num);
xllastarg();
return (cvfixnum((FIXTYPE)NewHandle(size)));
}
/* xnewptr - allocate memory */
LVAL xnewptr()
{
LVAL num;
long size;
num = xlgafixnum(); size = getfixnum(num);
xllastarg();
return (cvfixnum((FIXTYPE)NewPtr(size)));
}
/* xhiword - return the high order 16 bits of an integer */
LVAL xhiword()
{
unsigned int val;
val = (unsigned int)(getnumber() >> 16);
xllastarg();
return (cvfixnum((FIXTYPE)val));
}
/* xloword - return the low order 16 bits of an integer */
LVAL xloword()
{
unsigned int val;
val = (unsigned int)getnumber();
xllastarg();
return (cvfixnum((FIXTYPE)val));
}
/* xrdnohang - get the next character in the look-ahead buffer */
LVAL xrdnohang()
{
int ch;
xllastarg();
if ((ch = scrnextc()) == EOF)
return (NIL);
return (cvfixnum((FIXTYPE)ch));
}
/* ossymbols - enter important symbols */
ossymbols()
{
LVAL sym;
/* setup globals for the window handles */
sym = xlenter("*COMMAND-WINDOW*");
setvalue(sym,cvfixnum((FIXTYPE)cwindow));
sym = xlenter("*GRAPHICS-WINDOW*");
setvalue(sym,cvfixnum((FIXTYPE)gwindow));
}
======================== macint.c =============================================
/* macint.c - macintosh interface routines for xlisp */
#include <MacTypes.h>
#include <Quickdraw.h>
#include <WindowMgr.h>
#include <EventMgr.h>
#include <DialogMgr.h>
#include <MenuMgr.h>
#include <PackageMgr.h>
#include <StdFilePkg.h>
#include <MemoryMgr.h>
#include <DeskMgr.h>
#include <FontMgr.h>
#include <ControlMgr.h>
#include <SegmentLdr.h>
#include <FileMgr.h>
/* program limits */
#define SCRH 40 /* maximum screen height */
#define SCRW 100 /* maximum screen width */
#define CHARMAX 100 /* maximum number of buffered characters */
#define TIMEON 40 /* cursor on time */
#define TIMEOFF 20 /* cursor off time */
/* useful definitions */
#define MenuBarHeight 20
#define TitleBarHeight 20
#define SBarWidth 16
#define MinWidth 80
#define MinHeight 40
#define ScreenMargin 2
#define TextMargin 4
#define GHeight 232
/* menu id's */
#define appleID 1
#define fileID 256
#define editID 257
#define controlID 258
/* externals */
extern char *s_unbound;
extern char *PtoCstr();
/* screen dimensions */
int screenWidth;
int screenHeight;
/* command window (normal screen) */
int nHorizontal,nVertical,nWidth,nHeight;
/* command window (split screen) */
int sHorizontal,sVertical,sWidth,sHeight;
/* graphics window */
int gHorizontal,gVertical,gWidth,gHeight;
/* menu handles */
MenuHandle appleMenu;
MenuHandle fileMenu;
MenuHandle editMenu;
MenuHandle controlMenu;
/* misc variables */
OSType filetypes[] = { 'TEXT' };
/* font information */
int tmargin,lmargin;
int xinc,yinc;
/* command window */
WindowRecord cwrecord;
WindowPtr cwindow;
/* graphics window */
WindowRecord gwrecord;
WindowPtr gwindow;
/* window mode */
int splitmode;
/* cursor variables */
long cursortime;
int cursorstate;
int x,y;
/* screen buffer */
char screen[SCRH*SCRW],*topline,*curline;
int scrh,scrw;
/* type ahead buffer */
char charbuf[CHARMAX],*inptr,*outptr;
int charcnt;
macinit()
{
/* initialize the toolbox */
InitGraf(&thePort);
InitFonts();
InitWindows();
InitMenus();
TEInit();
InitDialogs(0L);
InitCursor();
/* setup the menu bar */
SetupMenus();
/* get the size of the screen */
screenWidth = screenBits.bounds.right - screenBits.bounds.left;
screenHeight = screenBits.bounds.bottom - screenBits.bounds.top;
/* Create the graphics and control windows */
gwindow = GetNewWindow(129,&gwrecord,-1L);
cwindow = GetNewWindow(128,&cwrecord,-1L);
/* establish the command window as the current port */
SetPort(cwindow);
/* compute the size of the normal command window */
nHorizontal = ScreenMargin;
nVertical = MenuBarHeight + TitleBarHeight + ScreenMargin - 2;
nWidth = screenWidth - (ScreenMargin * 2) - 1;
nHeight = screenHeight - MenuBarHeight - TitleBarHeight - (ScreenMargin * 2);
/* compute the size of the split command window */
sHorizontal = nHorizontal;
sVertical = nVertical + GHeight + 1;
sWidth = nWidth;
sHeight = nHeight - GHeight - 1;
/* compute the size of the graphics window */
gHorizontal = nHorizontal;
gVertical = MenuBarHeight + ScreenMargin;
gWidth = screenWidth - (ScreenMargin * 2);
gHeight = GHeight;
/* move and size the graphics window */
MoveWindow(gwindow,gHorizontal,gVertical,0);
SizeWindow(gwindow,gWidth,gHeight,0);
/* setup the font, size and writing mode for the command window */
TextFont(monaco); TextSize(9); TextMode(srcCopy);
/* setup command mode */
scrsplit(FALSE);
/* disable the Cursor */
cursorstate = -1;
/* setup the input ring buffer */
inptr = outptr = charbuf;
charcnt = 0;
/* lock the font in memory */
SetFontLock(-1);
}
SetupMenus()
{
appleMenu = GetMenu(appleID); /* setup the apple menu */
AddResMenu(appleMenu,'DRVR');
InsertMenu(appleMenu,0);
fileMenu = GetMenu(fileID); /* setup the file menu */
InsertMenu(fileMenu,0);
editMenu = GetMenu(editID); /* setup the edit menu */
InsertMenu(editMenu,0);
controlMenu = GetMenu(controlID); /* setup the control menu */
InsertMenu(controlMenu,0);
DrawMenuBar();
}
int scrgetc()
{
CursorOn();
while (charcnt == 0)
DoEvent();
CursorOff();
return (scrnextc());
}
int scrnextc()
{
int ch;
if (charcnt > 0) {
ch = *outptr++; charcnt--;
if (outptr >= &charbuf[CHARMAX])
outptr = charbuf;
}
else {
charcnt = 0;
ch = -1;
}
return (ch);
}
scrputc(ch)
int ch;
{
switch (ch) {
case '\r':
x = 0;
break;
case '\n':
nextline(&curline);
if (++y >= scrh) {
y = scrh - 1;
scrollup();
}
break;
case '\t':
do { scrputc(' '); } while (x & 7);
break;
case '\010':
if (x) x--;
break;
default:
if (ch >= 0x20 && ch < 0x7F) {
scrposition(x,y);
DrawChar(ch);
curline[x] = ch;
if (++x >= scrw) {
nextline(&curline);
if (++y >= scrh) {
y = scrh - 1;
scrollup();
}
x = 0;
}
}
break;
}
}
scrdelete()
{
scrputc('\010');
scrputc(' ');
scrputc('\010');
}
scrclear()
{
curline = screen;
for (y = 0; y < SCRH; y++)
for (x = 0; x < SCRW; x++)
*curline++ = ' ';
topline = curline = screen;
x = y = 0;
}
scrflush()
{
inptr = outptr = charbuf;
charcnt = -1;
osflush();
}
scrposition(x,y)
int x,y;
{
MoveTo((x * xinc) + lmargin,(y * yinc) + tmargin);
}
DoEvent()
{
EventRecord myEvent;
SystemTask();
CursorUpdate();
while (GetNextEvent(everyEvent,&myEvent))
switch (myEvent.what) {
case mouseDown:
DoMouseDown(&myEvent);
break;
case keyDown:
case autoKey:
DoKeyPress(&myEvent);
break;
case activateEvt:
DoActivate(&myEvent);
break;
case updateEvt:
DoUpdate(&myEvent);
break;
}
}
DoMouseDown(myEvent)
EventRecord *myEvent;
{
WindowPtr whichWindow;
switch (FindWindow(myEvent->where,&whichWindow)) {
case inMenuBar:
DoMenuClick(myEvent);
break;
case inSysWindow:
SystemClick(myEvent,whichWindow);
break;
case inDrag:
DoDrag(myEvent,whichWindow);
break;
case inGoAway:
DoGoAway(myEvent,whichWindow);
break;
case inGrow:
DoGrow(myEvent,whichWindow);
break;
case inContent:
DoContent(myEvent,whichWindow);
break;
}
}
DoMenuClick(myEvent)
EventRecord *myEvent;
{
long choice;
if (choice = MenuSelect(myEvent->where))
DoCommand(choice);
}
DoDrag(myEvent,whichWindow)
EventRecord *myEvent;
WindowPtr whichWindow;
{
Rect dragRect;
SetRect(&dragRect,0,MenuBarHeight,screenWidth,screenHeight);
InsetRect(&dragRect,ScreenMargin,ScreenMargin);
DragWindow(whichWindow,myEvent->where,&dragRect);
}
DoGoAway(myEvent,whichWindow)
EventRecord *myEvent;
WindowPtr whichWindow;
{
if (TrackGoAway(whichWindow,myEvent->where))
wrapup();
}
DoGrow(myEvent,whichWindow)
EventRecord *myEvent;
WindowPtr whichWindow;
{
Rect sizeRect;
long newSize;
if (whichWindow != FrontWindow() && whichWindow != gwindow)
SelectWindow(whichWindow);
else {
SetRect(&sizeRect,MinWidth,MinHeight,screenWidth,screenHeight-MenuBarHeight);
newSize = GrowWindow(whichWindow,myEvent->where,&sizeRect);
if (newSize) {
EraseRect(&whichWindow->portRect);
SizeWindow(whichWindow,LoWord(newSize),HiWord(newSize),-1);
InvalRect(&whichWindow->portRect);
SetupScreen();
scrflush();
}
}
}
DoContent(myEvent,whichWindow)
EventRecord *myEvent;
WindowPtr whichWindow;
{
if (whichWindow != FrontWindow() && whichWindow != gwindow)
SelectWindow(whichWindow);
}
DoKeyPress(myEvent)
EventRecord *myEvent;
{
long choice;
if (FrontWindow() == cwindow) {
if (myEvent->modifiers & 0x100) {
if (choice = MenuKey((char)myEvent->message))
DoCommand(choice);
}
else {
if (charcnt < CHARMAX) {
*inptr++ = myEvent->message & 0xFF; charcnt++;
if (inptr >= &charbuf[CHARMAX])
inptr = charbuf;
}
}
}
}
DoActivate(myEvent)
EventRecord *myEvent;
{
WindowPtr whichWindow;
whichWindow = (WindowPtr)myEvent->message;
SetPort(whichWindow);
if (whichWindow == cwindow)
DrawGrowIcon(whichWindow);
}
DoUpdate(myEvent)
EventRecord *myEvent;
{
WindowPtr whichWindow;
GrafPtr savePort;
GetPort(&savePort);
whichWindow = (WindowPtr)myEvent->message;
SetPort(whichWindow);
BeginUpdate(whichWindow);
EraseRect(&whichWindow->portRect);
if (whichWindow == cwindow) {
DrawGrowIcon(whichWindow);
RedrawScreen();
}
EndUpdate(whichWindow);
SetPort(savePort);
}
DoCommand(choice)
long choice;
{
int theMenu,theItem;
/* decode the menu choice */
theMenu = HiWord(choice);
theItem = LoWord(choice);
CursorOff();
HiliteMenu(theMenu);
switch (theMenu) {
case appleID:
DoAppleMenu(theItem);
break;
case fileID:
DoFileMenu(theItem);
break;
case editID:
DoEditMenu(theItem);
break;
case controlID:
DoControlMenu(theItem);
break;
}
HiliteMenu(0);
CursorOn();
}
pascal aboutfilter(theDialog,theEvent,itemHit)
DialogPtr theDialog; EventRecord *theEvent; int *itemHit;
{
return (theEvent->what == mouseDown ? -1 : 0);
}
DoAppleMenu(theItem)
int theItem;
{
DialogRecord mydialog;
char name[256];
GrafPtr gp;
int n;
switch (theItem) {
case 1:
GetNewDialog(129,&mydialog,-1L);
ModalDialog(aboutfilter,&n);
CloseDialog(&mydialog);
break;
default:
GetItem(appleMenu,theItem,name);
GetPort(&gp);
OpenDeskAcc(name);
SetPort(gp);
break;
}
}
pascal int filefilter(pblock)
ParmBlkPtr pblock;
{
unsigned char *p; int len;
p = pblock->fileParam.ioNamePtr; len = *p++ &0xFF;
return (len >= 4 && strncmp(p+len-4,".lsp",4) == 0 ? 0 : -1);
}
DoFileMenu(theItem)
int theItem;
{
SFReply loadfile;
Point p;
switch (theItem) {
case 1: /* load */
case 2: /* load noisily */
p.h = 100; p.v = 100;
SFGetFile(p,"\P",filefilter,-1,filetypes,0L,&loadfile);
if (loadfile.good) {
HiliteMenu(0);
SetVol(0L,loadfile.vRefNum);
if (xlload(PtoCstr(loadfile.fName),1,(theItem == 1 ? 0 : 1)))
scrflush();
else
xlabort("load error");
}
break;
case 4: /* quit */
wrapup();
}
}
DoEditMenu(theItem)
int theItem;
{
switch (theItem) {
case 1: /* undo */
case 3: /* cut */
case 4: /* copy */
case 5: /* paste */
case 6: /* clear */
SystemEdit(theItem-1);
break;
}
}
DoControlMenu(theItem)
int theItem;
{
scrflush();
HiliteMenu(0);
switch (theItem) {
case 1: /* break */
xlbreak("user break",s_unbound);
break;
case 2: /* continue */
xlcontinue();
break;
case 3: /* clean-up error */
xlcleanup();
break;
case 4: /* Cancel input */
xlabort("input canceled");
break;
case 5: /* Top Level */
xltoplevel();
break;
case 7: /* split screen */
scrsplit(splitmode ? FALSE : TRUE);
break;
}
}
scrsplit(split)
int split;
{
ShowHide(cwindow,0);
if (split) {
CheckItem(controlMenu,7,-1);
ShowHide(gwindow,-1);
MoveWindow(cwindow,sHorizontal,sVertical,-1);
SizeWindow(cwindow,sWidth,sHeight,-1);
InvalRect(&cwindow->portRect);
SetupScreen();
}
else {
CheckItem(controlMenu,7,0);
ShowHide(gwindow,0);
MoveWindow(cwindow,nHorizontal,nVertical,-1);
SizeWindow(cwindow,nWidth,nHeight,-1);
InvalRect(&cwindow->portRect);
SetupScreen();
}
ShowHide(cwindow,-1);
splitmode = split;
}
SetupScreen()
{
FontInfo info;
Rect *pRect;
/* get font information */
GetFontInfo(&info);
/* compute the top and bottom margins */
tmargin = TextMargin + info.ascent;
lmargin = TextMargin;
/* compute the x and y increments */
xinc = info.widMax;
yinc = info.ascent + info.descent + info.leading;
/* compute the character dimensions of the screen */
pRect = &cwindow->portRect;
scrh = (pRect->bottom - (2 * TextMargin) - (SBarWidth - 1)) / yinc;
if (scrh > SCRH) scrh = SCRH;
scrw = (pRect->right - (2 * TextMargin) - (SBarWidth - 1)) / xinc;
if (scrw > SCRW) scrw = SCRW;
/* clear the screen */
scrclear();
}
CursorUpdate()
{
if (cursorstate != -1)
if (cursortime < TickCount()) {
scrposition(x,y);
if (cursorstate) {
DrawChar(' ');
cursortime = TickCount() + TIMEOFF;
cursorstate = 0;
}
else {
DrawChar('_');
cursortime = TickCount() + TIMEON;
cursorstate = 1;
}
}
}
CursorOn()
{
cursortime = TickCount();
cursorstate = 0;
}
CursorOff()
{
if (cursorstate == 1) {
scrposition(x,y);
DrawChar(' ');
}
cursorstate = -1;
}
RedrawScreen()
{
char *Line; int y;
Line = topline;
for (y = 0; y < scrh; y++) {
scrposition(0,y);
DrawText(Line,0,scrw);
nextline(&Line);
}
}
nextline(pline)
char **pline;
{
if ((*pline += SCRW) >= &screen[SCRH*SCRW])
*pline = screen;
}
scrollup()
{
RgnHandle updateRgn;
Rect rect;
int x;
updateRgn = NewRgn();
rect = cwindow->portRect;
rect.bottom -= SBarWidth - 1;
rect.right -= SBarWidth - 1;
ScrollRect(&rect,0,-yinc,updateRgn);
DisposeRgn(updateRgn);
for (x = 0; x < SCRW; x++)
topline[x] = ' ';
nextline(&topline);
}
======================== macstuff.c ==========================================
/* macstuff.c - macintosh interface routines for xlisp */
#include <stdio.h>
/* program limits */
#define LINEMAX 200 /* maximum line length */
/* externals */
extern FILE *tfp;
extern int x;
/* local variables */
static char linebuf[LINEMAX+1],*lineptr;
static int linepos[LINEMAX],linelen;
static long rseed = 1L;
osinit(name)
char *name;
{
/* initialize the mac interface routines */
macinit();
/* initialize the line editor */
linelen = 0;
}
osfinish()
{
}
oserror(msg)
{
char line[100],*p;
sprintf(line,"error: %s\n",msg);
for (p = line; *p != '\0'; ++p)
ostputc(*p);
}
int osrand(n)
int n;
{
long k1;
/* make sure we don't get stuck at zero */
if (rseed == 0L) rseed = 1L;
/* algorithm taken from Dr. Dobbs Journal, November 1985, Page 91 */
k1 = rseed / 127773L;
if ((rseed = 16807L * (rseed - k1 * 127773L) - k1 * 2836L) < 0L)
rseed += 2147483647L;
/* return a random number between 0 and n-1 */
return ((int)(rseed % (long)n));
}
FILE *osaopen(name,mode)
char *name,*mode;
{
return (fopen(name,mode));
}
FILE *osbopen(name,mode)
char *name,*mode;
{
char nmode[4];
strcpy(nmode,mode); strcat(nmode,"b");
return (fopen(name,nmode));
}
int osclose(fp)
FILE *fp;
{
return (fclose(fp));
}
int osagetc(fp)
FILE *fp;
{
return (getc(fp));
}
int osbgetc(fp)
FILE *fp;
{
return (getc(fp));
}
int osaputc(ch,fp)
int ch; FILE *fp;
{
return (putc(ch,fp));
}
int osbputc(ch,fp)
int ch; FILE *fp;
{
return (putc(ch,fp));
}
int ostgetc()
{
int ch,i;
if (linelen--) return (*lineptr++);
linelen = 0;
while ((ch = scrgetc()) != '\r')
switch (ch) {
case EOF:
return (ostgetc());
case '\010':
if (linelen > 0) {
linelen--;
while (x > linepos[linelen])
scrdelete();
}
break;
default:
if (linelen < LINEMAX) {
linebuf[linelen] = ch;
linepos[linelen] = x;
linelen++;
}
scrputc(ch);
break;
}
linebuf[linelen++] = '\n';
scrputc('\r'); scrputc('\n');
if (tfp)
for (i = 0; i < linelen; ++i)
osaputc(linebuf[i],tfp);
lineptr = linebuf; linelen--;
return (*lineptr++);
}
int ostputc(ch)
int ch;
{
if (ch == '\n')
scrputc('\r');
scrputc(ch);
if (tfp)
osaputc(ch,tfp);
return (1);
}
osflush()
{
lineptr = linebuf;
linelen = 0;
}
oscheck()
{
DoEvent();
}
=========================== osdefs.h =====================================
extern LVAL xptsize(),
xhidepen(),xshowpen(),xgetpen(),xpensize(),xpenmode(),
xpenpat(),xpennormal(),xmoveto(),xmove(),xlineto(),xline(),
xshowgraphics(),xhidegraphics(),xcleargraphics(),
xtool(),xtool16(),xtool32(),xnewhandle(),xnewptr(),
xhiword(),xloword(),xrdnohang();
=========================== osptrs.h =====================================
{ "HIDEPEN", S, xhidepen }, /* 300 */
{ "SHOWPEN", S, xshowpen }, /* 301 */
{ "GETPEN", S, xgetpen }, /* 302 */
{ "PENSIZE", S, xpensize }, /* 303 */
{ "PENMODE", S, xpenmode }, /* 304 */
{ "PENPAT", S, xpenpat }, /* 305 */
{ "PENNORMAL", S, xpennormal }, /* 306 */
{ "MOVETO", S, xmoveto }, /* 307 */
{ "MOVE", S, xmove }, /* 308 */
{ "LINETO", S, xlineto }, /* 309 */
{ "LINE", S, xline }, /* 310 */
{ "SHOW-GRAPHICS", S, xshowgraphics }, /* 311 */
{ "HIDE-GRAPHICS", S, xhidegraphics }, /* 312 */
{ "CLEAR-GRAPHICS", S, xcleargraphics }, /* 313 */
{ "TOOLBOX", S, xtool }, /* 314 */
{ "TOOLBOX-16", S, xtool16 }, /* 315 */
{ "TOOLBOX-32", S, xtool32 }, /* 316 */
{ "NEWHANDLE", S, xnewhandle }, /* 317 */
{ "NEWPTR", S, xnewptr }, /* 318 */
{ "HIWORD", S, xhiword }, /* 319 */
{ "LOWORD", S, xloword }, /* 320 */
{ "READ-CHAR-NO-HANG", S, xrdnohang }, /* 321 */
{ "COMMAND-POINT-SIZE", S, xptsize }, /* 322 */
======================== Xlisp.Rsrc ==========================================
XLisp.Rsrc
TYPE WIND
,128
XLISP version 2.0
41 4 339 508
InVisible GoAway
0
0
TYPE WIND
,129
Graphics Window
22 4 254 508
InVisible NoGoAway
2
0
TYPE DLOG
,129
About XLISP
50 100 290 395
Visible NoGoAway
3
0
129
TYPE DITL
,129
9
staticText
20 20 40 275
XLISP v2.0, February 6, 1988
staticText
40 20 60 275
Copyright (c) 1988, by David Betz
staticText
60 20 80 275
All Rights Reserved
staticText
90 20 110 275
Author contact information:
staticText
110 40 130 275
David Betz
staticText
130 40 150 275
127 Taylor Road
staticText
150 40 170 275
Peterborough, NH 03458
staticText
170 40 190 275
(603) 924-6936
staticText
200 20 220 275
Portions Copyright Think Technologies
TYPE MENU
,1
\14
About XLISP
(-
TYPE MENU
,256
File
Load.../L
Load Noisily.../N
(-
Quit/Q
TYPE MENU
,257
Edit
Undo/Z
(-
Cut/X
Copy/C
Paste/V
Clear
TYPE MENU
,258
Control
Break/B
Continue/P
Clean Up Error/G
Cancel Input/U
Top Level/T
(-
Split Screen/S
======================== Alles ist gemacht ==================================
--
Eric F. Johnson, Boulware Technologies, Inc.
415 W. Travelers Trail, Burnsville, MN 55337 USA. Phone: +1 612-894-0313.
erc@pai.mn.org - or - bungia!pai!erc
(We have a very dumb mailer, so please send a bang-!-style return address.)
------------------------------
End of Scheme Digest
********************
∂13-Nov-89 2258 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #243
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 13 Nov 89 22:58:42 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA00904; Tue, 14 Nov 89 01:57:31 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Tue, 14 Nov 89 01:56:02 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa28797;
14 Nov 89 1:17 EST
Date: 14 NOV 89 00:08:19 EST
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.lcs.mit.edu>
Subject: Scheme Digest #243
To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Message-Id: <8911140117.aa28797@mintaka.lcs.mit.edu>
Scheme Digest #243 14 NOV 89 00:08:19 EST
Today's Topics:
Scheme BibTex file
XScheme Question.....
XScheme Question.....
Scheme to Commonlisp
Scheme to Commonlisp
Scheme -> C compilers?
- and / with one argument should be identity functions.
----------------------------------------------------------------------
Message-Id: <8911130651.AA18763@zurich.ai.mit.edu>
From: "Stewart M. Clamen" <clamen@cs.cmu.edu>
Date: Mon, 13 Nov 89 01:51:18 EST
Subject: Scheme BibTex file
Reply-To: clamen+@cs.cmu.edu
Has anyone out there composed a BibTex (or Scribe) bibliography file
for Scheme papers and books? It doesn't have to be complete. I will
happily add to it.
------------------------------------------------------------------------------
Stewart M. Clamen
School of Computer Science, Carnegie Mellon University
Pittsburgh, PA 15213-3890
INTERNET: clamen@CS.CMU.EDU
USENET: ...!uunet!"clamen@cs.cmu.edu"
------------------------------
Date: 13 Nov 89 11:28:49 GMT
From: Rajeev Pandey <umber.CS.ORST.EDU!rpandey@cs.orst.edu>
Subject: XScheme Question.....
Message-Id: <13736@orstcs.CS.ORST.EDU>
My apologies if this question has been answered before, but:
Is there some network site from which I can ftp the XScheme source?
I have seen a recent posting stating XScheme binaries were available through
BIX (Byte Info Exchange), but how about on the net?
I have a copy of the source for version 0.16 (Jan. 9, 89), and was also
wondering whether this is the latest version or not.
Many thanx in advance for any information.
--------
Department of Computer Science | Rajeev "Raju" Pandey
Computer Science Building 100 |
Oregon State University | Internet: rpandey@cs.orst.edu
Corvallis, OR 97331-3902 U.S.A. | UUCP: tektronix!orstcs!rpandey
(503) 737-3273 fax: (503) 737-3014| UUCP: hplabs!hp-pcd!orstcs!rpandey
------------------------------
Date: 13 Nov 89 13:37:21 GMT
From: "Brent W. Benson" <rochester!uhura.cc.rochester.edu!bwbe_c50@cu-arpa.cs.cornell.edu>
Subject: Re: XScheme Question.....
Message-Id: <4005@ur-cc.UUCP>
In article <13736@orstcs.CS.ORST.EDU> rpandey@umber.CS.ORST.EDU
(Rajeev Pandey) writes:
>My apologies if this question has been answered before, but:
>
>Is there some network site from which I can ftp the XScheme source?
>
The sources and binaries for XScheme are available at many ftp
sites. I obtained my sources (and PC binaries) from
terminator.cc.umich.edu (35.1.33.8). Enjoy!
Brent Benson
(bwbe_c50@uhura.cc.rochester.edu)
------------------------------
Date: Mon, 13 Nov 89 14:32:23 est
From: Jonathan Rees <jar@zurich.ai.mit.edu>
Message-Id: <8911131932.AA26435@zurich.ai.mit.edu>
Subject: Scheme to Commonlisp
Date: Wed, 08 Nov 89 12:38:51 +0000
From: Simon Ross <S.Ross@cs.ucl.ac.uk>
Does anyone have any advice or experience with converting a
program in Scheme to CommonLisp (in this case Texas Instruments
Scheme and Vax Commonlisp)? If there is some nifty program out
there that could do the job?
An old version of Pseudoscheme comes with the official VAX LISP
distribution from DEC; see the LISP$EXAMPLES directory. It lets you
run Scheme code in Common Lisp, but doesn't include a file translator.
You can get a newer version of Pseudoscheme that does include a file
translator by anonymous ftp from
zurich.ai.mit.edu:/pub/pseudo/pseudo-2-7.tar. Documentation is in
file README. Upward continuations and true tail recursion aren't
supported, but it does turn appropriately written Scheme loops into
Common Lisp PROG forms.
If you want true tail recursion or upward continuations, your task is
much more difficult.
------------------------------
Date: 13 Nov 89 19:32:23 GMT
From: Jonathan Rees <ZURICH.AI.MIT.EDU!jar@bloom-beacon.mit.edu>
Subject: Scheme to Commonlisp
Message-Id: <8911131932.AA26435@zurich.ai.mit.edu>
Date: Wed, 08 Nov 89 12:38:51 +0000
From: Simon Ross <S.Ross@cs.ucl.ac.uk>
Does anyone have any advice or experience with converting a
program in Scheme to CommonLisp (in this case Texas Instruments
Scheme and Vax Commonlisp)? If there is some nifty program out
there that could do the job?
An old version of Pseudoscheme comes with the official VAX LISP
distribution from DEC; see the LISP$EXAMPLES directory. It lets you
run Scheme code in Common Lisp, but doesn't include a file translator.
You can get a newer version of Pseudoscheme that does include a file
translator by anonymous ftp from
zurich.ai.mit.edu:/pub/pseudo/pseudo-2-7.tar. Documentation is in
file README. Upward continuations and true tail recursion aren't
supported, but it does turn appropriately written Scheme loops into
Common Lisp PROG forms.
If you want true tail recursion or upward continuations, your task is
much more difficult.
------------------------------
Date: 13 Nov 89 19:42:43 GMT
From: Garey Mills <gtm!garey@sun.com>
Subject: Scheme -> C compilers?
Message-Id: <34756@gtm.uucp>
In 1985 MIT put out a memo on C Scheme which listed the versions
of Scheme then available in the public domain. Among them was
Vincennes Scheme, and in MIT's description they noted that a
Scheme-to-C compiler was also available. I have also
heard of such a compiler existing from other sources, but no one
was sure from where.
I cannot get in touch with the guy responsible for Vincennes
Scheme, so I'm asking generally. Is such a compiler available? Is
it public domain? Where can it be had?
Any info would help.
Thanks,
Garey Mills (garey@gtm.EBAY.sun.com)
------------------------------
Date: 13 Nov 89 17:17:21 GMT
From: Via Fons Botman <mcsun!hp4nl!star.cs.vu.nl!xerox@uunet.uu.net>
Subject: - and / with one argument should be identity functions.
Message-Id: <4520@ski.cs.vu.nl>
PLease, let's *not* define (- X) and (/ X) to be something else
than X. It might be the source of obscure errors in (admittedly
ugly) code like:
(define (net-gain gain losses) (apply - gain losses))
Besides that, it may be cute, but it is neither clear nor
consistent, and therefore not "in the spirit of Scheme".
At least, that's my opinion.
------------------------------
End of Scheme Digest
********************
∂14-Nov-89 2229 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #244
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 14 Nov 89 22:29:32 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA20887; Wed, 15 Nov 89 01:28:25 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Wed, 15 Nov 89 01:27:01 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa23537;
15 Nov 89 0:57 EST
Date: 15 NOV 89 00:08:43 EST
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.lcs.mit.edu>
Subject: Scheme Digest #244
To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Message-Id: <8911150057.aa23537@mintaka.lcs.mit.edu>
Scheme Digest #244 15 NOV 89 00:08:43 EST
Today's Topics:
- and / with one argument should be identity functions.
Scheme or LISP in Smalltalk?
Scheme -> C compilers?
Scheme or LISP in Smalltalk?
- and / with one argument should be identity functions.
----------------------------------------------------------------------
Date: 13 Nov 89 17:17:21 GMT
From: Via Fons Botman <mcsun!hp4nl!star.cs.vu.nl!xerox@uunet.uu.net>
Subject: - and / with one argument should be identity functions.
Message-Id: <4520@skiscs.vu.nl>
PLease, let's *not* define (- X) and (/ X) to be something else
than X. It might be the source of obscure errors in (admittedly
ugly) code like:
(define (net-gain gain losses) (apply - gain losses))
Besides that, it may be cute, but it is neither clear nor
consistent, and therefore not "in the spirit of Scheme".
At least, that's my opinion.
------------------------------
Date: 14 Nov 89 04:49:01 GMT
From: Jordan Bortz <gem.mps.ohio-state.edu!apple!well!frobozz@think.com>
Subject: Scheme or LISP in Smalltalk?
Message-Id: <14557@well.UUCP>
Has anyone implemented a lisp or schme in Smalltalk?
How hard would it be to handle local variable bindings?
Jordan
--
***********************************************************************
* Jordan A. Bortz, Higher Level Software, Santa Cruz, CA *
* well!frobozz frobozz@well.sf.ca.us 408 - 476 - 8464 *
***********************************************************************
------------------------------
Message-Id: <8911141814.AA08492@jove.pa.dec.com>
Subject: Re: Scheme -> C compilers?
Date: Tue, 14 Nov 89 10:14:39 PST
From: bartlett@decwrl.dec.com
I don't know anything about the status of Vincennes Scheme, but a
Scheme->C compiler was also done at DEC WRL. Besides the required and
most of the optional items of R3RS, it includes: a compacting
generational collector, "expansion passing style" macros, a foreign
function call capability, and interfaces to X11's Xlib.
The software is not "public domain", but the license terms are fairly
liberal. Users of the software may use, modify, copy and distribute
the software and documentation, but may not offer it for sale or
transfer it for compensation (see the actual license for complete
details). Licensees must sign a license agreement and there is a $100
distribution fee for the software.
Send me a mail message with your postal address if you'd like further
information about licensing the software.
jfb
------------------------------
Date: 14 Nov 89 17:44:29 GMT
From: Timothy Hansell <laurel.cis.ohio-state.edu!hansell@ohio-state.arpa>
Subject: Re: Scheme or LISP in Smalltalk?
Message-Id: <73957@tut.cis.ohio-state.edu>
In article <14557@well.UUCP> frobozz@well.UUCP (Jordan Bortz) writes:
>
>Has anyone implemented a lisp or schme in Smalltalk?
>How hard would it be to handle local variable bindings?
> Jordan
>--
>***********************************************************************
>* Jordan A. Bortz, Higher Level Software, Santa Cruz, CA *
>* well!frobozz frobozz@well.sf.ca.us 408 - 476 - 8464 *
>***********************************************************************
I'm not sure about a lisp or a scheme, but
as to the question of local variable bindings ---
I have seen an addition to smalltalk workspaces, that
allowed for the creation and the persistent existence of variables
that were local to the workspace. When the workspace is remove the
variables go away. I'm not sure how close that is to what
you are talking about but this was implemented using a dictionary
in the workspace to keep track of local variables.
-tim
------------------------------
Date: Tue, 14 Nov 89 13:48:24 est
From: Chris Hanson <cph@zurich.ai.mit.edu>
Message-Id: <8911141848.AA03805@zurich.ai.mit.edu>
Subject: - and / with one argument should be identity functions.
Date: 13 Nov 89 17:17:21 GMT
From: Via Fons Botman <mcsun!hp4nl!star.cs.vu.nl!xerox@uunet.uu.net>
PLease, let's *not* define (- X) and (/ X) to be something else
than X.
Besides that, it may be cute, but it is neither clear nor
consistent, and therefore not "in the spirit of Scheme".
While it may be "cute" to use this pun, I think your argument about
clarity is incorrect: it is unusual for someone to be confused by this
usage of `-' (I don't know about `/'; I suspect it is rarely called
with one argument).
In practical terms, it is very much too late to reconsider this
decision. Both the R4RS and the Draft Standard for Scheme endorse
this inconsistency, and I can't recall any serious debate concerning
it. Perhaps if this issue had been raised five years ago something
might have been done, but at this point the inertia of standards and
implementations make such a change difficult; and this is especially
true as it is unlikely to be viewed (by those standardizers and
implementors) as being worth much effort.
Unfortunately this means that the Scheme community is a kind of
authoritarian structure -- but the standardization process is open to
anyone who cares to participate, so you too can be one of those in
authority. There are two relevant mailing lists:
rrrs-authors@ai.mit.edu
scheme-standard@ai.mit.edu
Interested parties should know that because the Draft Standard is
nearly completed, significant reexamination of basic issues on the
"scheme-standard" mailing list is inappropriate. The "rrrs-authors"
list is currently clearing up final details of R4RS, and debate is
welcomed on interesting issues for R5RS.
Archives of past discussions on each list are available by anonymous
ftp from "zurich.ai.mit.edu" in the directory "pub/scheme-mail/".
------------------------------
End of Scheme Digest
********************
∂15-Nov-89 2147 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #245
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 15 Nov 89 21:47:51 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA10481; Thu, 16 Nov 89 00:46:54 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Thu, 16 Nov 89 00:45:36 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa18493;
16 Nov 89 0:27 EST
Date: 16 NOV 89 00:08:49 EST
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.lcs.mit.edu>
Subject: Scheme Digest #245
To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Message-Id: <8911160027.aa18493@mintaka.lcs.mit.edu>
Scheme Digest #245 16 NOV 89 00:08:49 EST
Today's Topics:
Miranda release 2
- and / with one argument should be identity functions.
----------------------------------------------------------------------
Date: 14 Nov 89 23:10:18 GMT
From: "D.A.Turner" <mcsun!ukc!harrier.ukc.ac.uk!dat@uunet.uu.net>
Subject: Miranda release 2
Message-Id: <3117@harrier.ukc.ac.uk>
*** ANNOUNCEMENT ***
Miranda - Release Two
Miranda is a lazy functional language with polymorphic strong typing and
a simple but powerful module system. This is to inform anyone who may
be interested to know that a major new release of the Miranda system is
now available, incorporating a number of improvements - including
parameterised modules, unbounded size integers, and local polymorphism,
as well as a substantially faster implementation. It runs on a number
of machines under UNIX, including VAX, SUN-3, SUN-4, Apollo, HP 9000.
If you wish to receive a longer piece of electronic mail telling you
more about the Miranda system and how to obtain it, this can be
requested from
INTERNET: mira-request%ukc@nsfnet-relay.ac.uk
UUCP: mcvax!ukc!mira-request
JANET: mira-request@ukc.ac.uk
------------------------------
Date: Wed, 15 Nov 89 13:02:36 est
From: "Guillermo J. Rozas" <jinx@zurich.ai.mit.edu>
Message-Id: <8911151802.AA29786@zurich.ai.mit.edu>
Subject: - and / with one argument should be identity functions.
Reply-To: jinx@zurich.ai.mit.edu
Date: 13 Nov 89 17:17:21 GMT
From: Via Fons Botman <mcsun!hp4nl!star.cs.vu.nl!xerox@uunet.uu.net>
PLease, let's *not* define (- X) and (/ X) to be something else
than X. It might be the source of obscure errors in (admittedly
ugly) code like:
(define (net-gain gain losses) (apply - gain losses))
You should be using some version of reduce here. Apply is generally
the wrong thing to use.
Besides that, it may be cute, but it is neither clear nor
consistent, and therefore not "in the spirit of Scheme".
Why isn't it consistent? - and / are left associative and thus it is
natural and consistent to place the (right) identity on the left. :-)
Although (/ x) is atypical, that can hardly be said for -. Most
languages treat unary - specially. In addition, the "special" meaning
for both is traditional in Lisp.
------------------------------
End of Scheme Digest
********************
∂16-Nov-89 1154 @zurich.ai.mit.edu,@MC.lcs.mit.edu:chaynes@iuvax.cs.indiana.edu IEEE Scheme standard meeting announcement
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 16 Nov 89 11:54:28 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA20461; Thu, 16 Nov 89 14:51:53 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Thu, 16 Nov 89 14:50:33 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa13643;
16 Nov 89 14:37 EST
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 16 Nov 89 14:31:57 EST
Received: from iuvax.cs.indiana.edu by mintaka.lcs.mit.edu id aa12387;
16 Nov 89 14:07 EST
Received: by iuvax.cs.indiana.edu
Date: Thu, 16 Nov 89 14:06:17 -0500
From: Chris Haynes <chaynes@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu, scheme-standard@wheaties.ai.mit.edu,
scheme@mc.lcs.mit.edu, camp@csc.ti.com
Subject: IEEE Scheme standard meeting announcement
Message-Id: <8911161407.aa12387@mintaka.lcs.mit.edu>
The Fourth meeting of the IEEE/MSC/P1178 Working Group on Scheme will
be held from 1:30pm until about 5:30pm (continuing in the evening if
really necessary) on January 19, 1990, in the California Room of the
Cathedral Hill Hotel, Van Ness at Geary, San Francisco, California.
This follows the conclusion, at 12:30pm in the same hotel, of the
Principles of Programming Languages conference.
The main agenda item will be discussion of the third draft of the
standard, which has just been completed. Those on the working group
mailing list will receive a copy soon. Others may request copies from
me by email (chaynes@iuvax.cs.indiana.edu) or by writing:
Christopher Haynes
Department of Computer Science
Indiana University
Bloomington, Indiana 47405
∂16-Nov-89 1945 @zurich.ai.mit.edu,@eddie.mit.edu:garp!ogccse!mntgfx!plogan@EDDIE.MIT.EDU Please add my name to the mail list
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 16 Nov 89 19:45:34 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA27012; Thu, 16 Nov 89 22:42:02 EST
Received: from life.ai.mit.edu (life.ai.mit.edu) by zurich.ai.mit.edu; Thu, 16 Nov 89 22:40:48 est
Received: from EDDIE.MIT.EDU by life.ai.mit.edu (4.0/AI-4.10) id AA27004; Thu, 16 Nov 89 22:41:43 EST
Received: by EDDIE.MIT.EDU with UUCP (5.61/25-eef)
id AA27097; Thu, 16 Nov 89 22:41:21 EST
Received: by GARP.MIT.EDU with sendmail-5.61/4.7
id <AA20450@GARP.MIT.EDU>; Thu, 16 Nov 89 22:25:27 -0500
Received: by cse.ogc.edu (5.61+OGC_1.5 (named)/OGC_6.1+ogi)
id AA18687 ; Thu, 16 Nov 89 18:05:40 -0800
Received: by pdx.mentor.com ( 5.52 (74)/smail2.5/09-24-87/Mentor)
id AA10529; Thu, 16 Nov 89 16:04:43 PST
Date: Thu, 16 Nov 89 16:04:43 PST
From: ogccse!pdx.MENTOR.COM!plogan@garp.mit.edu (Patrick Logan)
Message-Id: <8911170004.AA10529@pdx.mentor.com>
To: rrrs-authors@ai.mit.edu
Subject: Please add my name to the mail list
Thanks.
--
Patrick Logan | ...!{decwrl,sequent,tessi}!mntgfx!plogan
Mentor Graphics Corporation | plogan@pdx.MENTOR.COM
Beaverton, Oregon |
∂16-Nov-89 2205 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #246
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 16 Nov 89 22:05:32 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA00359; Fri, 17 Nov 89 01:04:43 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Fri, 17 Nov 89 01:03:24 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa05257;
17 Nov 89 0:49 EST
Date: 17 NOV 89 00:09:18 EST
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.lcs.mit.edu>
Subject: Scheme Digest #246
To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Message-Id: <8911170049.aa05257@mintaka.lcs.mit.edu>
Scheme Digest #246 17 NOV 89 00:09:18 EST
Today's Topics:
IEEE Scheme standard meeting announcement
IEEE Scheme standard meeting announcement
Creating Runable programs from Scheme Code
----------------------------------------------------------------------
Date: Thu, 16 Nov 89 14:06:17 -0500
From: Chris Haynes <chaynes@iuvax.cs.indiana.edu>
Subject: IEEE Scheme standard meeting announcement
Message-ID: <8911161407.aa12387@mintaka.lcs.mit.edu>
The Fourth meeting of the IEEE/MSC/P1178 Working Group on Scheme will
be held from 1:30pm until about 5:30pm (continuing in the evening if
really necessary) on January 19, 1990, in the California Room of the
Cathedral Hill Hotel, Van Ness at Geary, San Francisco, California.
This follows the conclusion, at 12:30pm in the same hotel, of the
Principles of Programming Languages conference.
The main agenda item will be discussion of the third draft of the
standard, which has just been completed. Those on the working group
mailing list will receive a copy soon. Others may request copies from
me by email (chaynes@iuvax.cs.indiana.edu) or by writing:
Christopher Haynes
Department of Computer Science
Indiana University
Bloomington, Indiana 47405
------------------------------
Date: 16 Nov 89 19:06:17 GMT
From: Chris Haynes <IUVAX.CS.INDIANA.EDU!chaynes@bloom-beacon.mit.edu>
Subject: IEEE Scheme standard meeting announcement
Message-Id: <8911161407.aa12387@mintaka.lcs.mit.edu>
The Fourth meeting of the IEEE/MSC/P1178 Working Group on Scheme will
be held from 1:30pm until about 5:30pm (continuing in the evening if
really necessary) on January 19, 1990, in the California Room of the
Cathedral Hill Hotel, Van Ness at Geary, San Francisco, California.
This follows the conclusion, at 12:30pm in the same hotel, of the
Principles of Programming Languages conference.
The main agenda item will be discussion of the third draft of the
standard, which has just been completed. Those on the working group
mailing list will receive a copy soon. Others may request copies from
me by email (chaynes@iuvax.cs.indiana.edu) or by writing:
Christopher Haynes
Department of Computer Science
Indiana University
Bloomington, Indiana 47405
------------------------------
Date: 17 Nov 89 01:07:11 GMT
From: Ben Wildasin <silver!bwildasi@iuvax.cs.indiana.edu>
Subject: Creating Runable programs from Scheme Code
Message-Id: <29845@iuvax.cs.indiana.edu>
I've just started out using Chez Scheme on a VAX under Ultrix,
and I am interested in creating auto-executable files (i.e. those
runnable from the csh prompt) fom Scheme source code.
Is this possible?
a T d H v A a N n K c S e,
Ben Wildasin
**************************************************************************
Ben Wildasin bwildasi@silver.bacs.indiana.edu
**************************************************************************
------------------------------
End of Scheme Digest
********************
∂18-Nov-89 2113 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #247
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 18 Nov 89 21:13:12 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA04022; Sun, 19 Nov 89 00:11:36 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Sun, 19 Nov 89 00:10:08 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa16686;
19 Nov 89 0:05 EST
Date: 19 NOV 89 00:09:23 EST
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.lcs.mit.edu>
Subject: Scheme Digest #247
To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Message-Id: <8911190006.aa16686@mintaka.lcs.mit.edu>
Scheme Digest #247 19 NOV 89 00:09:23 EST
Today's Topics:
Elk/Scheme on IBM RT/PC
----------------------------------------------------------------------
Date: 18 Nov 89 12:26:43 GMT
From: Michael Pak <shuldig.Huji.AC.IL!misha@ucbvax.berkeley.edu>
Subject: Elk/Scheme on IBM RT/PC
Message-Id: <547@shuldig.Huji.Ac.IL>
I am looking for an Elk/Scheme interpreter for
IBM RT/PC workstation.
If you know whether one exists and where can I get it,
please E-mail me.
Thanks in advance,
Misha.
------------------------------
End of Scheme Digest
********************
∂19-Nov-89 2111 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #248
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 19 Nov 89 21:11:33 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA14668; Mon, 20 Nov 89 00:10:32 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Mon, 20 Nov 89 00:09:07 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa13907;
20 Nov 89 0:05 EST
Date: 20 NOV 89 00:09:20 EST
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.lcs.mit.edu>
Subject: Scheme Digest #248
To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Message-Id: <8911200005.aa13907@mintaka.lcs.mit.edu>
Scheme Digest #248 20 NOV 89 00:09:20 EST
Today's Topics:
----------------------------------------------------------------------
Date: Sun, 19 Nov 89 02:14:55 PST
From: Mad Bomber <c60a-4aw@web.berkeley.edu>
Message-Id: <8911191014.AA14032@weaver.berkeley.edu>
Dear Sirs:
Please send me information as to how I may obtain MacScheme, such as a source
and price.
Please send the information to: Collin Ong, 2650 Durant Ave. #202C, Berkeley,
CA 94720. Please do not respond to this email account as it will probably be
terminated shortly.
Thank you very much.
Collin Ong
------------------------------
End of Scheme Digest
********************
∂20-Nov-89 1208 mipsmag!dbetz@uunet.uu.net R4 report
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 20 Nov 89 12:08:32 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA23309; Mon, 20 Nov 89 15:02:35 EST
Received: from life.ai.mit.edu (life.ai.mit.edu) by zurich.ai.mit.edu; Mon, 20 Nov 89 15:01:02 est
Received: from uunet.uu.net by life.ai.mit.edu (4.0/AI-4.10) id AA23295; Mon, 20 Nov 89 15:02:01 EST
Received: from mipsmag.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA11406; Mon, 20 Nov 89 15:01:47 -0500
Received: by mipsmag.UUCP (smail2.5)
id AA03809; 20 Nov 89 10:54:03 EST (Mon)
Subject: R4 report
To: rrrs-authors@ai.mit.edu
Date: Mon, 20 Nov 89 10:54:03 EST
X-Mailer: ELM [version 2.2 PL13]
Message-Id: <8911201054.AA03805@mipsmag.UUCP>
From: mipsmag!dbetz@uunet.uu.net (David Betz)
Would it be possible to send me a copy of the R4 Scheme report? I'd like
to make sure that XScheme is compatible.
Thanks,
David Betz
∂22-Nov-89 2221 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #249
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Nov 89 22:21:00 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA07079; Thu, 23 Nov 89 01:17:13 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Thu, 23 Nov 89 01:15:12 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa23623;
23 Nov 89 0:56 EST
Date: 23 NOV 89 00:10:13 EST
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.lcs.mit.edu>
Subject: Scheme Digest #249
To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Message-Id: <8911230056.aa23623@mintaka.lcs.mit.edu>
Scheme Digest #249 23 NOV 89 00:10:13 EST
Today's Topics:
Request for Comments: A new n-ary function construction
----------------------------------------------------------------------
Date: Wed, 22 Nov 89 11:55:42 PST
From: Pavel.pa@xerox.com
Subject: Request for Comments: A new n-ary function construction
Message-ID: <891122-121343-4098@Xerox>
This note concerns an idea I've been kicking around for some time; I'm
probably going to implement the idea in Scheme Xerox and I'd like to get
comments on it from the community at large. You can consider yourselves as
design consultants...
I would like to avoid using ``rest lists'' in my Scheme code, especially at
the lowest levels, for a number of reasons: they are usually difficult to
optimize and I don't like the language-level preference for the list type
over, for example, vectors. To get around the problem, I thought of
extending the syntax of lambda-lists to the following:
<lambda-list> ::= <id>
| ( <id>* )
| ( <id>+ . <id> )
| ( <id>* "arbitrary" <id> <id> )
| ( <id>* "arbitrary" <id> <id> . <id> )
That is, you can now follow the ``required'' parameters by the marker
string "arbitrary" and two identifiers. The first of these will, on
invocation of the procedure, be bound to the number of ``extra'' arguments,
those not accounted for by the required parameters; it is an exact integer.
The second new identifier will be bound to a procedure of one argument, an
exact non-negative integer less than the extra argument count; it returns
the extra argument with that index.
[Note: I'll point out right here that nobody I've shown this to has liked
having strings in the lambda-list. It just seemed better to me than
&arbitrary or #!arbitrary. Suggestions are solicited.]
Thus, for example, one could write Common Lisp's LIST* as follows:
(define (list* first "arbitrary" n f)
(if (zero? n)
first
(cons first
(let loop ((i (- n 2))
(result (f (- n 1)))) ; last argument
(if (negative? i)
result
(loop (- i 1)
(cons (f i) result)))))))
The advantages of this approach are straightforward to see. On the
practical side, it is easily optimized in the case where the
argument-fetching function does not escape: all invocations can be
implemented as simple indexes into the actual argument vector on the stack
(or wherever). When the function does escape, its closure can probably be
allocated and filled in faster than the corresponding rest list. On the
language purity side, this seems to me a cleaner approach, using the more
fundamental data types of integers and procedures, rather than lists. It
also allows random access to the arguments when that's handy, as it was
above. This is more difficult with lists.
Of course, one of the common uses of rest lists is as eventual arguments to
APPLY. This is a fine idiom and so we should have a way to support a
corresponding idiom with this construct. Suppose that we had a new
primitive, called APPLYF for lack of a good name, defined as follows:
(APPLYF fn arg1 ... argK n f)
Applies the procedure FN to (K + N) arguments:
arg1 ... argK (f 0) ... (f n-1)
This new primitive can, of course, accept any N and F, not just those
acquired from the "arbitrary" mechanism:
(define (iota k)
(applyf vector k (lambda (i) (+ i 1))))
In the case where F did come from the the "arbitrary" mechanism, it is easy
to optimize the resulting code as a cheap argument-copying loop.
Sometimes, with rest lists, one wants to pass along to APPLY a tail of the
original list:
(define (foo . x)
(apply bar (cdr x)))
or some such. This can also be done with APPLYF:
(define (foo "arbitrary" n f)
(applyf bar (- n 1) (lambda (k) (f (+ k 1)))))
Granted, this isn't as concise, but the idea is more general. We can as
easily pass a prefix of the arguments:
(define (foo "arbitrary" n f)
(applyf bar (- n 1) f))
or just the even-indexed ones:
(define (foo "arbitrary" n f)
(applyf bar (quotient (+ n 1) 2)
(lambda (k) (f (* k 2)))))
In all of these cases, it's easy to optimize the resulting code to contain
no procedure calls and no allocation.
Some of you with longer memories may recognize the old MacLisp LEXPR
mechanism (or Interlisp LAMBDA*) in this facility. It's different in
important ways, though: the argument-fetching function is not a special
form taking a strange argument with dynamic scope, it is a normal Scheme
procedure with indefinite extent.
I've rambled enough for now; what do you folks think?
Pavel Curtis
Xerox PARC/CSL
------------------------------
End of Scheme Digest
********************
∂27-Nov-89 1034 FIBCLS05@fib.upc.es suscribe
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 27 Nov 89 10:34:07 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA17694; Mon, 27 Nov 89 13:28:47 EST
Received: from life.ai.mit.edu (life.ai.mit.edu) by zurich.ai.mit.edu; Mon, 27 Nov 89 13:27:21 est
Received: from mcsun.EU.net by life.ai.mit.edu (4.0/AI-4.10) id AA17673; Mon, 27 Nov 89 13:28:15 EST
Received: by mcsun.EU.net via EUnet; Mon, 27 Nov 89 19:27:54 +0100 (MET)
Received: by goya.dit.upm.es (EUnet) (3.2/6.2) Mon, 27 Nov 89 19:18:11 +0100
Date: 27 Nov 89 19:15 +0100
From: Enric Sesa i Nogueras <FIBCLS05@fib.upc.es>
To: rrrs-authors@ai.mit.edu
Message-Id: <93*FIBCLS05@FIB.UPC.ES>
Subject: suscribe
Return-Receipt-To: Enric Sesa i Nogueras <FIBCLS05@fib.upc.es>
Please add me to the mailing list.
My net address is FIBCLS05@FIB.UPC.ES
∂27-Nov-89 1621 ziggy@hx.lcs.mit.edu RE: COND/DO consistency
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 27 Nov 89 16:21:05 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA23533; Mon, 27 Nov 89 19:15:40 EST
Received: from life.ai.mit.edu (life.ai.mit.edu) by zurich.ai.mit.edu; Mon, 27 Nov 89 19:14:12 est
Received: from hx.LCS.MIT.EDU by life.ai.mit.edu (4.0/AI-4.10) id AA23528; Mon, 27 Nov 89 19:15:16 EST
Received: by hx.LCS.MIT.EDU (5.51/4.7); Mon, 27 Nov 89 19:11:14 EST
Date: Mon, 27 Nov 89 19:11:14 EST
From: ziggy@hx.lcs.mit.edu (Michael R. Blair)
Message-Id: <8911280011.AA09917@hx.LCS.MIT.EDU>
To: rrrs-authors@ai.mit.edu
Subject: RE: COND/DO consistency
I had proposed the following:
> | (DO ((<variable> <init> <step>)
> | ...)
> | (<test> <expression>...)
> | <command>...)
> |
> | If the <test> evaluates to a true value, then the value of the last
> | <expression> is returned as the result of the DO. If no <expression>s
> | are present, then the value of the DO expression is unspecified.
>
> I propose that this last line read "then the value of the <test> is
> returned as the value of the DO expression." for consistency with the
> way test clauses are handled in COND.
>
> Consequently, I propose that the rewrite rule for DO in section 7.3
> be changed to:
>
> | (DO ((<variable_1> <init_1> <step_1>)
> | ...)
> | (<test> <expression>...) ;; NB: <sequence> changed to <expr>...
> | <command_1>...)
> |
> | = (LETREC ((<loop>
> | (LAMBDA (<variable_1>...)
> | (COND (<test> <expression>...) ;; NB: COND
> | (ELSE <command_1> ;; not IF
> | ... ;;
> | (<loop> <step_1>...)))))) ;;
> | (<loop> <init_1>...))
Morry countered by generalizing this to have potentially many <test> clauses:
> | (DO ((<variable_1> <init_1> <step_1>)
> | ...)
> | ((<test> <expression>...) ;; NB: <sequence> changed to <expr>...
> | ...)
> | <command_1>...)
This is a more substantial change and, as Morry noted, it is not compatible with
the current DO syntax. I would like to add that I have never had occasion to
malign the language for not providing a more general exit <test> structure. To
point, I have adopted the following idiom:
(DEFINE call-with-nonlocal-exit call-with-current-continuation)
(DEFINE (first-such-that test-pred lst)
(call-with-nonlocal-exit
(LAMBDA (exit)
(DO ((to-do lst (CDR to-do)))
((NULL? to-do) *THE-CANONICAL-FAILURE-OBJECT*)
(LET ((next (CAR to-do)))
(COND ((test-pred next) (exit next))
((something-interesting? next) (exit (mumble next)))
...
))))))
I find this not excessively verbose and I actually enjoy the distinction between
the "normal" loop-variable-exhausted exit condition to the "exceptional"
short-cut-situation exit condition. I have generalized this into a
SHORT-CURCUIT-ACCUMULATE idiom which I use fairly often.
My point is that I would not like my initial painless proposal to be
overshadowed or superceeded by a more controversial counter-proposal. I really
have had occasion to want to return the result of the non-FALSE test. For
example, when I exit with the first element of a list which has a frame in a
possibly lengthy association list, I don't cherish the thought of probing for
the frame twice and I don't relish named-LET or LETREC as an alternative since
this obscures the DO-ish nature of the iteration. I prefer DO when doing DO-ish
doodles, but when faced with multiple exit conditions, I prefer the
nonlocal-exit idiom to Morry's more moribund morsel.
Cheers,
~Ziggy
∂27-Nov-89 2150 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #250
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 27 Nov 89 21:50:20 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA28083; Tue, 28 Nov 89 00:43:51 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Tue, 28 Nov 89 00:42:22 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa18432;
28 Nov 89 0:30 EST
Date: 28 NOV 89 00:10:25 EST
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.lcs.mit.edu>
Subject: Scheme Digest #250
To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Message-Id: <8911280030.aa18432@mintaka.lcs.mit.edu>
Scheme Digest #250 28 NOV 89 00:10:25 EST
Today's Topics:
Request for Comments: A new n-ary function construction
Scheme Digest #249
Request for Comments: A new n-ary function construction
----------------------------------------------------------------------
Date: Mon, 27 Nov 89 08:49:40 PST
From: Morris Katz <mkatz@garlic.stanford.edu>
Message-Id: <8911271649.AA04492@garlic.Stanford.EDU>
Subject: Request for Comments: A new n-ary function construction
Date: Wed, 22 Nov 89 11:55:42 PST
From: Pavel.pa@xerox.com
That is, you can now follow the ``required'' parameters by the marker
string "arbitrary" and two identifiers. The first of these will, on
invocation of the procedure, be bound to the number of ``extra'' arguments,
those not accounted for by the required parameters; it is an exact integer.
The second new identifier will be bound to a procedure of one argument, an
exact non-negative integer less than the extra argument count; it returns
the extra argument with that index.
I believe that it would be much cleaner to only use the second of the two extra
arguments. (i.e., the one which is bound to a procedure) The information
about the number of optional arguments which are supplied can be aquired
through the use of an arity function of the type previously discussed on the
rrrs-authors mailing list during a discussion on multiple values. I support
the arity approach because it is more general purpose and can be specified in a
manner that is orthoginal to the rest of Scheme. Why put in a special purpose
hack, when a more general solution is available.
-------------------------------------------------------------------------------
Morry Katz
katz@cs.stanford.edu
-------------------------------------------------------------------------------
------------------------------
From: Guy Steele <gls@think.com>
Date: Mon, 27 Nov 89 14:45:08 EST
Message-Id: <8911271945.AA01984@ungar.think.com>
Subject: Scheme Digest #249
Date: Wed, 22 Nov 89 11:55:42 PST
>From: Pavel.pa@xerox.com
Subject: Request for Comments: A new n-ary function construction
Message-ID: <891122-121343-4098@Xerox>
This note concerns an idea I've been kicking around for some time; I'm
probably going to implement the idea in Scheme Xerox and I'd like to get
comments on it from the community at large. You can consider yourselves as
design consultants...
...
[Note: I'll point out right here that nobody I've shown this to has liked
having strings in the lambda-list. It just seemed better to me than
&arbitrary or #!arbitrary. Suggestions are solicited.]
Instead of a string, how about using the number 69 ? :-)
--Guy
P.S. Otherwise it is an interesting idea. Are you sure that
improving the LEXPR mechanism isn't gilding a sow's ear?
------------------------------
Date: Mon, 27 Nov 89 15:29:55 PST
From: Morris Katz <mkatz@garlic.stanford.edu>
Message-Id: <8911272329.AA07264@garlic.Stanford.EDU>
Subject: Request for Comments: A new n-ary function construction
Date: Mon, 27 Nov 89 14:11:47 PST
From: Pavel.pa@Xerox.COM
To what procedure would you apply "arity" to get the answer?
In retrospect it is clear that my original message on this subject was so
cryptic as to be content free. I would propose having one extra argument which
would be bound to a procedure which would return the optional arguments as
multiple return values. For symetry reasons, a language which supports
multiple return values would require two types of arity functions: call-arity
and return-arity. (Please don't flame about the names. I just hate using foo
and bar as names when I can think of something semantically more meaningful.)
Call-arity is the procedure which is more commonly called arity and returns
information about the number of parameters which a function expect.
Return-arity is the procedure which returns information about the number of
return values to be returned by a function. An application of return-arity to
the special function which is bound to optional arguments would return
information about the number of optionals which were supplied.
I realize that this proposal goes far beyond Pavel's original question; but, I
believe that multiple return values should be integrated into Scheme for good
symetry reasons. I feel that this can be done in such a way that they will
actually solve many more problems than they create. Pavel's application is
only one of many examples where the multiple value approach actually leads to a
quite elegant solution.
-------------------------------------------------------------------------------
Morry Katz
katz@cs.stanford.edu
-------------------------------------------------------------------------------
------------------------------
End of Scheme Digest
********************
∂28-Nov-89 2128 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #251
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 28 Nov 89 21:28:39 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA16960; Wed, 29 Nov 89 00:25:15 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Wed, 29 Nov 89 00:23:53 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa25353;
29 Nov 89 0:21 EST
Date: 29 NOV 89 00:11:47 EST
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.lcs.mit.edu>
Subject: Scheme Digest #251
To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Message-Id: <8911290021.aa25353@mintaka.lcs.mit.edu>
Scheme Digest #251 29 NOV 89 00:11:47 EST
Today's Topics:
Scheme interface to MS Windows
----------------------------------------------------------------------
Message-Id: <8911281913.AA25876@gatech.edu>
Subject: Scheme interface to MS Windows
Date: Mon, 27 Nov 89 10:55:57 EST
From: Gene Pierce <gatech!rd1632.Dayton.NCR.com!pierce@eddie.mit.edu>
Is There an MS Windows interface for Scheme ?
--
Gene Pierce (Gene.Pierce@Dayton.NCR.COM)
Software Technology, R&D Division (1 513 445-1079)
NCR Corporation
1700 Patterson Blvd., Dayton Ohio 45479
------------------------------
End of Scheme Digest
********************
∂29-Nov-89 0403 ramsdell@linus.mitre.org Naming Baby Doe
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 29 Nov 89 04:03:02 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA20603; Wed, 29 Nov 89 06:57:33 EST
Received: from linus.mitre.org ([129.83.100.103]) by zurich.ai.mit.edu; Wed, 29 Nov 89 06:56:08 est
Received: from huxley.mitre.org by linus.mitre.org (5.59/RCF-3S)
id AA06012; Wed, 29 Nov 89 06:54:03 EST
Posted-Date: Wed, 29 Nov 89 06:54:16 EST
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA12808; Wed, 29 Nov 89 06:54:17 EST
From: ramsdell@linus.mitre.org
Message-Id: <8911291154.AA12808@huxley.mitre.org>
To: rrrs-authors@zurich.ai.mit.edu
Subject: Naming Baby Doe
Date: Wed, 29 Nov 89 06:54:16 EST
Voting for the name of Baby Doe ends this week. If you have not voted
already please do so. I have received votes from the following
people:
From: "Stewart M. Clamen" <clamen@CS.CMU.EDU>
From: Alan Bawden <bawden@parc.xerox.com>
From: Bruce Duba <duba@rice.edu>
From: Chris Haynes <chaynes@iuvax.cs.indiana.edu>
From: Evan Kirshenbaum <evan%hplerk@hplabs.hp.com>
From: Gyro@reasoning.com
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
From: Mark A. Sheldon <death@ZERMATT.LCS.MIT.EDU>
From: Pavel.pa@Xerox.COM
From: Robert Hieb <hieb@iuvax.cs.indiana.edu>
From: cadence!dyb@iuvax.cs.indiana.edu (R. Kent Dybvig)
From: cph@zurich.ai.mit.edu (Chris Hanson)
From: halstead@crl.dec.com
From: jar@zurich.ai.mit.edu (Jonathan Rees)
From: jinx@zurich.ai.mit.edu (Guillermo J. Rozas)
From: kend%mrloog.wr.tek.com@RELAY.CS.NET
From: markf@zurich.ai.mit.edu
From: mkatz@garlic.stanford.edu (Morris Katz)
John
∂29-Nov-89 0528 ramsdell@linus.mitre.org Re: COND/DO consistency
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 29 Nov 89 05:27:54 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA21283; Wed, 29 Nov 89 08:22:42 EST
Received: from linus.mitre.org ([129.83.100.103]) by zurich.ai.mit.edu; Wed, 29 Nov 89 08:21:20 est
Received: from huxley.mitre.org by linus.mitre.org (5.59/RCF-3S)
id AA06838; Wed, 29 Nov 89 08:19:14 EST
Posted-Date: Wed, 29 Nov 89 08:19:27 EST
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA12866; Wed, 29 Nov 89 08:19:28 EST
From: ramsdell@linus.mitre.org
Message-Id: <8911291319.AA12866@huxley.mitre.org>
To: rrrs-authors@zurich.ai.mit.edu
Subject: Re: COND/DO consistency
In-Reply-To: Your message of Mon, 27 Nov 89 19:11:14 -0500.
<8911280011.AA09917@hx.LCS.MIT.EDU>
Date: Wed, 29 Nov 89 08:19:27 EST
I think Blair's suggestion on changing the semantics of DO is quite
good. I'm not sure what else say except this topic should be put on
the agenda for the next R5RS meeting.
John
> | (DO ((<variable_1> <init_1> <step_1>)
> | ...)
> | (<test> <expression>...) ;; NB: <sequence> changed to <expr>...
> | <command_1>...)
> |
> | = (LETREC ((<loop>
> | (LAMBDA (<variable_1>...)
> | (COND (<test> <expression>...) ;; NB: COND
> | (ELSE <command_1> ;; not IF
> | ... ;;
> | (<loop> <step_1>...)))))) ;;
> | (<loop> <init_1>...))
∂02-Dec-89 2110 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #252
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 2 Dec 89 21:09:52 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA24087; Sun, 3 Dec 89 00:08:22 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Sun, 3 Dec 89 00:06:55 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa09515;
3 Dec 89 0:08 EST
Date: 3 DEC 89 00:07:55 EST
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.lcs.mit.edu>
Subject: Scheme Digest #252
To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Message-Id: <8912030008.aa09515@mintaka.lcs.mit.edu>
Scheme Digest #252 3 DEC 89 00:07:55 EST
Today's Topics:
new version of SIOD, Scheme in One Defun
----------------------------------------------------------------------
Date: Sat, 2 Dec 89 09:26:46 EST
From: gjc@bu-it.bu.edu
Message-Id: <8912021426.AA11190@buit4.bu.edu>
Subject: new version of SIOD, Scheme in One Defun
Version 1.5 of SIOD is now available via anonymous ftp to bu-it.bu.edu,
CD to "src/gjc" and get "siod-v1.5-shar".
New features:
* modularized with small main program in one file, scheme runtime
and REPL in another.
* stop-and-copy or mark-and-sweep GC selectable via command line argument,
-g0 for mark-and-sweek, -g1 for stop-and-copy.
* On 3 architectures tested, VAX, SUN3, ENCORE, the code in -g0 mode
to mark the stack and registers is effective. Therefore GC can happen
at any time during EVAL, READ, etc.
-gjc
------------------------------
End of Scheme Digest
********************
∂03-Dec-89 2133 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #253
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 3 Dec 89 21:33:42 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA04110; Mon, 4 Dec 89 00:28:56 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Mon, 4 Dec 89 00:27:26 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22649;
4 Dec 89 0:19 EST
Date: 4 DEC 89 00:07:54 EST
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.lcs.mit.edu>
Subject: Scheme Digest #253
To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Message-Id: <8912040019.aa22649@mintaka.lcs.mit.edu>
Scheme Digest #253 4 DEC 89 00:07:54 EST
Today's Topics:
SCHEME-MEMBERSHIP
SIOD, release 2.0
----------------------------------------------------------------------
Date: Sun, 3 Dec 89 12:31 CST
From: ELEE6L2@uhvax1.uh.edu
Subject: SCHEME-MEMBERSHIP
Message-ID: <8912031332.aa05160@mintaka.lcs.mit.edu>
I am about to begin my Masters thesis in the area of Neural Networks and I have been using the Rochester Connectionist Simulator for that.But I am not having Scheme which I want ot understand.Could you e-mail it to me please.
K.V.Krishna Iyer,Electrical Engg. Dept.,University of Houston,TX 77004.
------------------------------
Message-Id: <8912032103.AA03092@schizo.samsung.com>
Reply-To: gjc@mitech.com
Date: Sun, 3 Dec 89 15:58:37 EDT
From: gjc@mitech.com
Subject: SIOD, release 2.0
Also available is siod-v2.0-shar, which has call-with-current-continuation.
------------------------------
End of Scheme Digest
********************
∂04-Dec-89 2113 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #254
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 4 Dec 89 21:12:55 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA18988; Tue, 5 Dec 89 00:11:35 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Tue, 5 Dec 89 00:09:59 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa04831;
5 Dec 89 0:07 EST
Date: 5 DEC 89 00:07:58 EST
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.lcs.mit.edu>
Subject: Scheme Digest #254
To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Message-Id: <8912050008.aa04831@mintaka.lcs.mit.edu>
Scheme Digest #254 5 DEC 89 00:07:58 EST
Today's Topics:
LENGTH optimization?
----------------------------------------------------------------------
Message-Id: <2837816627-224788@RTS-13>
Date: Mon, 4 Dec 89 21:23:47 EST
From: ziggy@hx.lcs.mit.edu
Subject: LENGTH optimization?
Are there any LISP implementations that attempt to make LENGTH
of a list be a less than linear-time operation. I can imagine
especially for immutable lists that this is easily achieved.
Only SET-CDR! seems to be a fly in the ointment.
~Ziggy
------------------------------
End of Scheme Digest
********************
∂05-Dec-89 1901 ramsdell@linus.mitre.org Baby Doe name: CALL-WITH-VALUES --- generator first.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 5 Dec 89 19:01:43 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA11010; Tue, 5 Dec 89 21:45:33 EST
Received: from linus.mitre.org ([129.83.100.103]) by zurich.ai.mit.edu; Tue, 5 Dec 89 21:43:38 est
Received: from huxley.mitre.org by linus.mitre.org (5.59/RCF-3S)
id AA03234; Mon, 4 Dec 89 09:02:04 EST
Posted-Date: Mon, 04 Dec 89 09:02:00 EST
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA01872; Mon, 4 Dec 89 09:02:01 EST
From: ramsdell@linus.mitre.org
Message-Id: <8912041402.AA01872@huxley.mitre.org>
To: rrrs-authors@zurich.ai.mit.edu
Cc: ramsdell@linus.mitre.org
Subject: Baby Doe name: CALL-WITH-VALUES --- generator first.
Date: Mon, 04 Dec 89 09:02:00 EST
The results of the Baby Doe naming vote is that the name is
CALL-WITH-VALUES, and the generator is to come first.
Enclosed is the resulting agenda item to be discussed at the next
meeting for the Revised↑5 Report on Scheme. I hope we can at least
agree on this proposal, but I hope it does not impede consideration of
proposals that deal with related matters currently unspecified.
John
#! /bin/sh
# This is a shell archive, meaning:
# 1. Remove everything above the #! /bin/sh line.
# 2. Save the resulting text in a file.
# 3. Execute the file with /bin/sh (not csh) to create the files:
# mv.tex
# This archive created: Mon Dec 4 08:44:04 1989
export PATH; PATH=/bin:$PATH
if test -f 'mv.tex'
then
echo shar: will not over-write existing file "'mv.tex'"
else
cat << \SHAR_EOF > 'mv.tex'
%%% Multiple values compromise proposal of December 4, 1989.
%%% This is raw TeX.
\advance\hsize by -5cm
\def\mvcall{call-with-values}
\def\mvcontinue{values}
The editors are directed to add text to R$↑5$RS so as to include the
procedures {\tt \mvcontinue{}} and {\tt\mvcall{}} consistent with the
following definitions. The {\tt \mvcontinue{}} procedure takes any
number of arguments, and simply passes them to its continuation. The
{\tt\mvcall{}} procedure takes a thunk and a procedure, and calls the
thunk with a continuation that, when passed some values, calls the
procedure that was the second argument to the {\tt\mvcall{}} procedure
with those values as arguments. Except for continuations created by
the {\tt\mvcall{}} procedure, all continuations take exactly one
value, as now; the effect of passing no value or more than one value
to continuations that were not created by the {\tt\mvcall{}} procedure
is unspecified (as indeed it is unspecified now).
Suggested formal semantics:
$$\hbox{\it \mvcontinue{}} = \lambda\epsilon↑*\kappa . \kappa\epsilon↑*$$
$$\hbox{\it \mvcall{}} = \hbox{\it twoarg }(\lambda \epsilon_1
\epsilon_2\kappa . \hbox{ \it applicate } \epsilon_1 \langle \rangle
\lambda \epsilon↑* . \hbox{ \it applicate } \epsilon_2
\epsilon↑* \kappa)$$
\end
SHAR_EOF
fi # end of overwriting check
# End of shell archive
exit 0
**************************************************************************
Voting record.
**************************************************************************
|-------------------------------------------------------------------------
Continuation Linker | Continuation Invoker. | Generator first? | Vote
|-----------------------|-----------------------|------------------|------
| | |
CALL-WITH-VALUES | VALUES | yes | 8
| | |
|-----------------------|-----------------------|------------------|------
markf@zurich.ai.mit.edu (Mark Friedman)
jinx@zurich.ai.mit.edu (Guillermo J. Rozas)
cadence!dyb@iuvax.cs.indiana.edu (R. Kent Dybvig)
Pavel.pa@Xerox.COM
evan%hplerk@hplabs.hp.com (Evan Kirshenbaum)
cph@zurich.ai.mit.edu (Chris Hanson)
halstead@crl.dec.com
"Stewart M. Clamen" <clamen@CS.CMU.EDU>
|-----------------------|-----------------------|------------------|------
| | |
WITH-VALUES | VALUES | yes | 5
| | |
|-----------------------|-----------------------|------------------|------
Mark A. Sheldon <death@ZERMATT.LCS.MIT.EDU>
Alan Bawden <bawden@parc.xerox.com>
Chris Haynes <chaynes@iuvax.cs.indiana.edu>
Robert Hieb <hieb@iuvax.cs.indiana.edu>
arthur@zurich.ai.mit.edu (Arthur Gleckler)
|-----------------------|-----------------------|------------------|------
| | |
CALL-WITH-VALUES | VALUES | no | 3
| | |
|-----------------------|-----------------------|------------------|------
mkatz@garlic.stanford.edu (Morris Katz)
kend%mrloog.wr.tek.com@RELAY.CS.NET
Bruce Duba <duba@rice.edu>
|-----------------------|-----------------------|------------------|------
| | |
CONTINUING | CONTINUE | yes | 2
| | |
|-----------------------|-----------------------|------------------|------
Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
ramsdell@linus.mitre.org (John D. Ramsdell)
|-----------------------|-----------------------|------------------|------
| | |
COMPOSE-CONTINUATION | CONTINUE | no | 0
| | |
|-----------------------|-----------------------|------------------|------
|-----------------------|-----------------------|------------------|------
| | |
CALL-WITH-CONTINUATION | CONTINUE | yes | 1
| | |
|-----------------------|-----------------------|------------------|------
Gyro@reasoning.com
|-----------------------|-----------------------|------------------|------
Other:
jar@zurich.ai.mit.edu (Jonathan Rees) voted for the generator first.
∂05-Dec-89 2007 Pavel.pa@xerox.com Dynamic binding, ballot
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 5 Dec 89 20:07:31 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA11657; Tue, 5 Dec 89 22:59:00 EST
Received: from Xerox.COM (xerox.com) by zurich.ai.mit.edu; Tue, 5 Dec 89 22:57:36 est
Received: from Semillon.ms by ArpaGateway.ms ; 05 DEC 89 19:57:43 PST
Date: Tue, 05 Dec 89 19:56:43 PST
From: Pavel.pa@xerox.com
Subject: Dynamic binding, ballot
To: RRRS-Authors@zurich.ai.mit.edu
Cc: Pavel.pa@xerox.com
Reply-To: Pavel.pa@xerox.com
Message-Id: <891205-195743-13899@Xerox>
Will suggested that I send out another ballot concerning whether or not to
include dynamic binding, as described in a separate message (and in earlier
ones), in an appendix to R4RS. I include such a ballot below. Please send
your ballots to me before the new year. I will compile the results and
send them out at that time.
Pavel
|--------|-------------------------------------------------------------------|
| |
|
| | I do not object to including a description of dynamic binding,
as |
| | defined in the recent message to RRRS-Authors, in an appendix to
|
| | R4RS.
|
| |
|
|--------|-------------------------------------------------------------------|
| |
|
| | I do not object to including a description of dynamic binding,
|
| | similar to that in the recent message to RRRS-Authors, in an
|
| | appendix to R4RS as long as it reflects the changes I want.
|
| | A brief overview of my desired changes appears below this
ballot. |
| |
|
|--------|-------------------------------------------------------------------|
| |
|
| | I object to including a description of dynamic binding, similar
|
| | to that in the recent message to RRRS-Authors, in an appendix to
|
| | R4RS.
|
| |
|
|--------|-------------------------------------------------------------------|
Additional comments:
∂05-Dec-89 2012 Pavel.pa@xerox.com Dynamic binding, description for ballot
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 5 Dec 89 20:12:33 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA11633; Tue, 5 Dec 89 22:56:32 EST
Received: from Xerox.COM (xerox.com) by zurich.ai.mit.edu; Tue, 5 Dec 89 22:54:55 est
Received: from Semillon.ms by ArpaGateway.ms ; 05 DEC 89 19:55:27 PST
Date: Tue, 05 Dec 89 19:55:11 PST
From: Pavel.pa@xerox.com
Subject: Dynamic binding, description for ballot
To: RRRS-Authors@zurich.ai.mit.edu
Cc: Pavel.pa@xerox.com
Message-Id: <891205-195527-13896@Xerox>
Here is the BASH proposal for dynamic binding again with a slight bit of
rewriting to avoid saying that the objects being manipulated here are
``dynamic variables'' since some folks dislike the notion that a
computation can return a ``variable'' of any kind. I have changed the name
to simply ``dynamic''.
I have also added the predicate DYNAMIC? which is true only of dynamics and
specified that dynamics are disjoint from all other Scheme types.
A separate message contains a ballot on the possible inclusion of a
description of dynamic binding in an appendix to R4RS.
Pavel
===========
We propose adding five procedures and one derived expression type to
Scheme:
(MAKE-DYNAMIC obj) [Procedure]
Create and return a new ``dynamic'' whose global value is obj.
(DYNAMIC? obj) [Procedure]
Return true if and only if obj is a dynamic. No object satisfying DYNAMIC?
satisfies any of the other standard type predicates.
(DYNAMIC-REF dyn) [Procedure]
Return the value of the given dynamic in the current dynamic environment.
(DYNAMIC-SET! dyn obj) [Procedure]
Change the value of the given dynamic to obj in the current dynamic
environment. The returned value is unspecified.
(CALL-WITH-DYNAMIC-BINDING dyn obj thunk) [Procedure]
Invoke and return the value of the given thunk in a new, nested dynamic
environment in which the given dynamic has been bound to a new location
whose initial contents are the value obj. This dynamic environment has
precisely the same extent as the invocation of the thunk and is thus
captured by continuations created within that invocation and re-established
by those continuations when they are invoked.
(DYNAMIC-BIND ((var-expr val-expr) ...) . body) [Syntax]
Evaluates the var-exprs and val-exprs in an unspecified order; the
var-exprs should yield dynamics. Returns the result of evaluating the body
in a new, nested dynamic environment in which the given dynamics have new
bindings, initialized to the given values. This dynamic environment has
precisely the same extent as the evaluation of the body and is thus
captured by continuations created within the body and re-established by
those continuations on invocation.
The DYNAMIC-BIND derived expression type has the following rewrite rule:
(dynamic-bind ((<var-expr1> <val-expr1>)
(<var-expr2> <val-expr2>)
...
(<var-exprN> <val-exprN>))
. <body>)
is equivalent to
(let ((var1 <var-expr1>)
(val1 <val-expr1>)
(var2 <var-expr2>)
(val2 <val-expr2>)
...
(varN <var-exprN>)
(valN <val-exprN>)
(body-thunk (lambda () . <body>)))
(call-with-dynamic-binding var1 val1
(lambda ()
(call-with-dynamic-binding var2 val2
(lambda ()
...
(call-with-dynamic-binding varN valN
body-thunk) ... )))))
===========
Notes:
-- Given ``dynamic-wind'', a portable shallow-binding implementation of the
proposal can be written for all single-processor implementations of Scheme.
It was suggested at the BASH meeting that something like this be done and
placed in the library. As stated in earlier messages, multiprocessor
implementations will have to implement it more primitively; Jinx has
pointed out, however, that two simple procedures for accessing the
process-specific dynamic environment suffice.
-- This proposal does not specify whether or not
``call-with-dynamic-binding'' tail-calls the given thunk. I think this is
proper. It is possible for deep-binding implementations to use tail-call,
but only at the expense of passing the dynamic environment on every
procedure call. In shallow binding implementations, it is probably not
possible at all.
===========
∂05-Dec-89 2313 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #255
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 5 Dec 89 23:13:22 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA13759; Wed, 6 Dec 89 01:03:09 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Wed, 6 Dec 89 01:01:16 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa20604;
6 Dec 89 0:47 EST
Date: 6 DEC 89 00:08:00 EST
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.lcs.mit.edu>
Subject: Scheme Digest #255
To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Message-Id: <8912060047.aa20604@mintaka.lcs.mit.edu>
Scheme Digest #255 6 DEC 89 00:08:00 EST
Today's Topics:
LENGTH optimization?
Consing Rest Args Considered Harmful
----------------------------------------------------------------------
From: Dan Cerys <cerys@bbn.com>
Subject: LENGTH optimization?
Date: Tue, 5 Dec 89 1:43:16 EST
Message-ID: <8912050150.aa08964@mintaka.lcs.mit.edu>
Are there any LISP implementations that attempt to make LENGTH
of a list be a less than linear-time operation. I can imagine
especially for immutable lists that this is easily achieved.
Only SET-CDR! seems to be a fly in the ointment.
The Zetalisps of old (probably still true of Explorers and Genera) used to
provide an ART-Q-LIST array type. Such arrays were a cross between a
general (ART-Q) array and a list. Application of the wonderfully mnemonic
G-L-P function would return the "list" equivalent of the array. Preventing
any flies from mucking about, SET-CDR! (RPLACD) on this "list" was an
error. Because of these restrictions, it would seem that LENGTH of such
"lists" would require constant time, regardless of length (just like
determining LENGTH of an array). However, I don't know if this was the
case.
Dan
------------------------------
Date: Tue, 5 Dec 1989 18:48-EST
From: Barak.Pearlmutter@f.gp.cs.cmu.edu
Subject: Consing Rest Args Considered Harmful
Message-Id: <Tue.Dec.5.18:48:04.1989/bap@F.GP.CS.CMU.EDU>
In Oaklisp, Kevin and I used a somewhat ideosyncratic solution to the
rest args problem. A form like (lambda (a b . c) BODY) makes a
procedure of at least two arguments, and BODY can refer to the first
two, A and B. But the token C is not a variable; it is special syntax
indicating that an indeterminite number of rest arguments are being
passed. Since it is just syntax, it can't be closed over. It can be
used in only one context: in a tail recursive call that gets you out of
BODY, you must terminate the call with ". C". And all exits from body
must be tail recursive, and must do this. For instance, you could write
(define (foo a b . c)
(list a 'aye b 'bee . c))
There is a way to find out how many extra arguments were passed, as in
the following form. REST-LENGTH is syntax though, not a procedure. I'm
still not sure if this was a good idea, although it is simple enough to
provide.
(define (foo a b . c)
(if (> (rest-length c) 5)
(list 'lots 'of . c)
(list 'little . c)))
A number of utility functions are provided for manipulating the rest
arguments. For instance, LISTIFY-ARGS takes at least one argument, a
procedure, which it calls on a list made up of any additional arguments.
So to write a function which takes an arbitrary number of arguments and
returns its second, you could write
(define (second-arg a x . rest)
(listify-args (lambda (l) x) . rest))
Other functions useful for rest argument consumption are also provided.
We felt that this mechanism provided the bare minimum of functionality
necessary in the base level language to work with rest arguments,
without imposing undue implementation constraints. In using it, we
found that almost all uses of rest arguments fit naturally into the
paradigm, and very rarely is there any reason to listify the rest
arguments. In particular, this is true of things like + and * which can
basically eat there arguments left to right until they're all gone.
[ In passing, I should mention that the compatibility package makes
dotted rest args behave in the usual ugly but standard way. ]
------------------------------
End of Scheme Digest
********************
∂06-Dec-89 0833 ramsdell@linus.mitre.org R4RS Appendix
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 6 Dec 89 08:33:47 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA18825; Wed, 6 Dec 89 11:22:06 EST
Received: from linus.mitre.org ([129.83.100.103]) by zurich.ai.mit.edu; Wed, 6 Dec 89 11:20:42 est
Received: from huxley.mitre.org by linus.mitre.org (5.59/RCF-3S)
id AA05879; Wed, 6 Dec 89 07:25:29 EST
Posted-Date: Wed, 06 Dec 89 07:25:36 EST
Received: by huxley.mitre.org (4.0/RCF-4C)
id AA04116; Wed, 6 Dec 89 07:25:38 EST
From: ramsdell@linus.mitre.org
Message-Id: <8912061225.AA04116@huxley.mitre.org>
To: rrrs-authors@zurich.ai.mit.edu
Subject: R4RS Appendix
In-Reply-To: Your message of Tue, 05 Dec 89 19:56:43 -0800.
<891205-195743-13899@Xerox>
Date: Wed, 06 Dec 89 07:25:36 EST
Maybe we should decide what the subject of the R4RS Appendix is to be,
and then decide whether it should include proposals for dynamic
binding, multiple values, records, and of course, macros. I am
getting the impression that the Appendix is to be a place for mature
proposals containing additions to the Scheme language. A proposal is
deemed mature if it gets enough Email votes. Without addressing any
particular proposal, is that general approach to the liking of all?
John
∂06-Dec-89 0856 jar@zurich.ai.mit.edu Dynamic binding, description for ballot
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 6 Dec 89 08:56:00 PST
Received: from zurich.ai.mit.edu ([18.43.0.158]) by life.ai.mit.edu (4.0/AI-4.10) id AA19224; Wed, 6 Dec 89 11:47:44 EST
Received: from localhost by zurich.ai.mit.edu; Wed, 6 Dec 89 11:46:28 est
Date: Wed, 6 Dec 89 11:46:28 est
From: jar@zurich.ai.mit.edu (Jonathan Rees)
Message-Id: <8912061646.AA04089@zurich.ai.mit.edu>
To: Pavel.pa@xerox.com
Cc: RRRS-Authors@zurich.ai.mit.edu
In-Reply-To: Pavel.pa@Xerox.COM's message of Tue, 05 Dec 89 19:55:11 PST <891205-195527-13896@Xerox>
Subject: Dynamic binding, description for ballot
The description is incomplete; it doesn't specify how dynamic bindings
interact with call-with-current-continuation.
∂06-Dec-89 0901 jar@zurich.ai.mit.edu Dynamic binding, description for ballot
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 6 Dec 89 09:00:15 PST
Received: from zurich.ai.mit.edu ([18.43.0.158]) by life.ai.mit.edu (4.0/AI-4.10) id AA19272; Wed, 6 Dec 89 11:51:18 EST
Received: from localhost by zurich.ai.mit.edu; Wed, 6 Dec 89 11:49:55 est
Date: Wed, 6 Dec 89 11:49:55 est
From: jar@zurich.ai.mit.edu (Jonathan Rees)
Message-Id: <8912061649.AA04094@zurich.ai.mit.edu>
To: Pavel.pa@xerox.com
Cc: RRRS-Authors@zurich.ai.mit.edu
In-Reply-To: Pavel.pa@Xerox.COM's message of Tue, 05 Dec 89 19:55:11 PST <891205-195527-13896@Xerox>
Subject: Dynamic binding, description for ballot
Well... what I meant was that it doesn't EXPLICITLY talk about
c-w-c-c. There is wording that talks about continuations. I think it
would help to include an example or two in the proposal, including one
or two using call-with-current-continuation. Also the proposal should
outline how to change the formal semantics to accomodate dynamics.
∂06-Dec-89 1039 pavel.parc@arisia.xerox.com Dynamic binding, ballot (with better line breaks)
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 6 Dec 89 10:39:37 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA20833; Wed, 6 Dec 89 13:32:38 EST
Received: from arisia.Xerox.COM (arisia.xerox.com) by zurich.ai.mit.edu; Wed, 6 Dec 89 13:30:56 est
From: pavel.parc@arisia.xerox.com
Received: by arisia.Xerox.COM
(5.61+/IDA-1.2.8/gandalf) id AA02215; Wed, 6 Dec 89 10:27:45 -0800
Message-Id: <8912061827.AA02215@arisia.Xerox.COM>
Date: Wed, 6 Dec 89 10:27:45 -0800
To: RRRS-Authors@zurich.ai.mit.edu
Subject: Dynamic binding, ballot (with better line breaks)
Reply-To: pavel.parc@arisia.xerox.com
[Resent to fix nasty line-breaking problems...]
Will suggested that I send out another ballot concerning whether or not to
include dynamic binding, as described in a separate message (and in earlier
ones), in an appendix to R4RS. I include such a ballot below. Please send
your ballots to me before the new year. I will compile the results and
send them out at that time.
Pavel
|--------|-------------------------------------------------------------------|
| | |
| | I do not object to including a description of dynamic binding, as |
| | defined in the recent message to RRRS-Authors, in an appendix to |
| | R4RS. |
| | |
|--------|-------------------------------------------------------------------|
| | |
| | I do not object to including a description of dynamic binding, |
| | similar to that in the recent message to RRRS-Authors, in an |
| | appendix to R4RS as long as it reflects the changes I want. |
| | A brief overview of my desired changes appears below this ballot. |
| | |
|--------|-------------------------------------------------------------------|
| | |
| | I object to including a description of dynamic binding, similar |
| | to that in the recent message to RRRS-Authors, in an appendix to |
| | R4RS. |
| | |
|--------|-------------------------------------------------------------------|
Additional comments:
∂06-Dec-89 1212 Pavel.pa@xerox.com Re: Dynamic binding, description for ballot
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 6 Dec 89 12:12:11 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA22326; Wed, 6 Dec 89 15:05:31 EST
Received: from Xerox.COM (xerox.com) by zurich.ai.mit.edu; Wed, 6 Dec 89 15:03:53 est
Received: from Semillon.ms by ArpaGateway.ms ; 06 DEC 89 11:49:36 PST
Date: Wed, 06 Dec 89 11:49:13 PST
From: Pavel.pa@xerox.com
Subject: Re: Dynamic binding, description for ballot
In-Reply-To: <8912061646.AA04089@zurich.ai.mit.edu>
To: jar@zurich.ai.mit.edu
Cc: RRRS-Authors@zurich.ai.mit.edu
Message-Id: <891206-114936-1679@Xerox>
My intent was that the following sentence in the description of
CALL-WITH-DYNAMIC-BINDING described (informally) how the dynamic
environment interacts with call/cc:
``This dynamic has precisely the same extent as the invocation of the thunk
and is thus captured by continuations created within that invocation and
re-established by those continuations when they are invoked.''
I could write down the intent by modifying the formal semantics at the end
of the report (to pass around the dynamic environment), but that's seems a
bit heavy weight for such a forum. Alternatively, I could write some
examples showing how it works. The idea is simply that call/cc captures
the current dynamic environment in the procedure it creates and that
procedure re-establishes that environment when invoked.
Is this intent unclear to anyone on this list, or are we discussing how it
should be described in a report?
Pavel
∂06-Dec-89 2345 cph@zurich.ai.mit.edu Dynamic binding, ballot (with better line breaks)
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 6 Dec 89 23:45:03 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA01894; Thu, 7 Dec 89 02:36:26 EST
Received: from localhost by zurich.ai.mit.edu; Thu, 7 Dec 89 02:35:12 est
Date: Thu, 7 Dec 89 02:35:12 est
From: cph@zurich.ai.mit.edu (Chris Hanson)
Message-Id: <8912070735.AA15947@zurich.ai.mit.edu>
To: rrrs-authors-list-1@zurich.ai.mit.edu,
rrrs-authors-list-2@zurich.ai.mit.edu,
rrrs-authors-list-3@zurich.ai.mit.edu
In-Reply-To: pavel.parc@arisia.Xerox.COM's message of Wed, 6 Dec 89 10:27:45 -0800 <8912061827.AA02215@arisia.Xerox.COM>
Subject: Dynamic binding, ballot (with better line breaks)
From: pavel.parc@arisia.Xerox.COM
Date: Wed, 6 Dec 89 10:27:45 -0800
|--------|-------------------------------------------------------------------|
| | |
| | I do not object to including a description of dynamic binding, as |
| | defined in the recent message to RRRS-Authors, in an appendix to |
| | R4RS. |
| | |
|--------|-------------------------------------------------------------------|
| | |
| | I do not object to including a description of dynamic binding, |
| | similar to that in the recent message to RRRS-Authors, in an |
| X | appendix to R4RS as long as it reflects the changes I want. |
| | A brief overview of my desired changes appears below this ballot. |
| | |
|--------|-------------------------------------------------------------------|
| | |
| | I object to including a description of dynamic binding, similar |
| | to that in the recent message to RRRS-Authors, in an appendix to |
| | R4RS. |
| | |
|--------|-------------------------------------------------------------------|
Additional comments:
I'm unhappy with the names; using "dynamic" as a noun in this context
rubs me the wrong way (in fact I think using "dynamic" as a noun in
-any- context is a little strange). I think "dynamic-variable" is a
good name for this thing, despite the fact that it's unpopular. You
at one point suggested "dynamic-identifier"; this also seems
reasonable to me, although you expressed some discomfort with it.
Whatever name is chosen, I think that the constructor and predicate
should contain it: e.g. `MAKE-DYNAMIC-IDENTIFIER' and
`DYNAMIC-IDENTIFIER?'. I'm happy with the names of the other
procedures.
∂07-Dec-89 0723 halstead@crl.dec.com Dynamic binding vote
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 7 Dec 89 07:23:43 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA05407; Thu, 7 Dec 89 10:18:24 EST
Received: from crl.dec.com ([192.58.206.2]) by zurich.ai.mit.edu; Thu, 7 Dec 89 10:16:34 est
Received: by crl.dec.com; id AA05410; Thu, 7 Dec 89 10:16:57 -0500
Message-Id: <8912071516.AA05612@crlrhh.crl.dec.com>
To: pavel.parc@arisia.xerox.com
Cc: halstead@crl.dec.com, rrrs-authors@zurich.ai.mit.edu
Subject: Dynamic binding vote
Date: Thu, 07 Dec 89 10:16:51 EST
From: halstead@crl.dec.com
|--------|-------------------------------------------------------------------|
| | |
| | I do not object to including a description of dynamic binding, as |
| | defined in the recent message to RRRS-Authors, in an appendix to |
| | R4RS. |
| | |
|--------|-------------------------------------------------------------------|
| | |
| | I do not object to including a description of dynamic binding, |
| XX | similar to that in the recent message to RRRS-Authors, in an |
| XX | appendix to R4RS as long as it reflects the changes I want. |
| | A brief overview of my desired changes appears below this ballot. |
| | |
|--------|-------------------------------------------------------------------|
| | |
| | I object to including a description of dynamic binding, similar |
| | to that in the recent message to RRRS-Authors, in an appendix to |
| | R4RS. |
| | |
|--------|-------------------------------------------------------------------|
Additional comments:
I agree with Chris Hanson that "dynamic" is a strange noun. I too would
favor DYNAMIC-VARIABLE, which seems to me to be quite descriptive of
this object type. But another possibility is DYNAMIC-CELL, to indicate
the idea of a mutable entity that can hold a single value but is not a
"variable" in the sense of being closely associated with any particular
identifier in the source program. I don't care too much for
DYNAMIC-IDENTIFIER because I have always thought of an "identifier" as
a variable _name_ (i.e., a symbol, in the case of a Scheme source program)
and variable names are one thing that these "dynamics" are _not_!
If there is concern that, e.g., DYNAMIC-VARIABLE-REF is too much typing
for the poor Scheme hacker, then I suggest an abbreviation such as DV
(hence DV-REF) as being in the spirit of abbreviating
CALL-WITH-CURRENT-CONTINUATION to CALL/CC or CWCC. -Bert
∂07-Dec-89 1218 KMP@stony-brook.scrc.symbolics.com Baby Doe name: CALL-WITH-VALUES --- generator first.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 7 Dec 89 12:18:37 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA09872; Thu, 7 Dec 89 15:09:10 EST
Received: from STONY-BROOK.SCRC.Symbolics.COM (stony-brook.scrc.symbolics.com) by zurich.ai.mit.edu; Thu, 7 Dec 89 15:07:54 est
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 703461; 6 Dec 89 17:30:00 EST
Date: Wed, 6 Dec 89 17:29 EST
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Subject: Baby Doe name: CALL-WITH-VALUES --- generator first.
To: ramsdell@linus.mitre.org
Cc: rrrs-authors@zurich.ai.mit.edu, kmp@stony-brook.scrc.symbolics.com
In-Reply-To: <8912041402.AA01872@huxley.mitre.org>
Message-Id: <19891206222957.0.KMP@BOBOLINK.SCRC.Symbolics.COM>
One way to interpret the response would be to that 11 people knew that
a particular thing the other 8 liked was deficient, but they went in
different directions trying to fix it. Sigh. Well, I hate it but
at least it's settled and we can get with it.
∂07-Dec-89 1451 rpg@lucid.com Dynamic binding, ballot (with better line breaks)
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 7 Dec 89 14:51:12 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA12539; Thu, 7 Dec 89 17:47:05 EST
Received: from lucid.com (lucid.com) by zurich.ai.mit.edu; Thu, 7 Dec 89 17:44:33 est
Received: from rose ([192.31.212.83]) by LUCID.COM id AA16783g; Thu, 7 Dec 89 14:39:53 PST
Received: by rose id AA09274g; Thu, 7 Dec 89 14:42:02 PST
Date: Thu, 7 Dec 89 14:42:02 PST
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8912072242.AA09274@rose>
To: RRRS-Authors@zurich.ai.mit.edu
Subject: Dynamic binding, ballot (with better line breaks)
|--------|-------------------------------------------------------------------|
| | |
| | I do not object to including a description of dynamic binding, as |
| | defined in the recent message to RRRS-Authors, in an appendix to |
| | R4RS. |
| | |
|--------|-------------------------------------------------------------------|
| | |
| | I do not object to including a description of dynamic binding, |
| | similar to that in the recent message to RRRS-Authors, in an |
| | appendix to R4RS as long as it reflects the changes I want. |
| | A brief overview of my desired changes appears below this ballot. |
| | |
|--------|-------------------------------------------------------------------|
| X X | |
| X X | I object to including a description of dynamic binding, similar |
| X | to that in the recent message to RRRS-Authors, in an appendix to |
| X X | R4RS. |
| X X | |
|--------|-------------------------------------------------------------------|
Additional comments:
There are several things I find wrong about this proposal. The first is the
reason I object to inclusion, and the rest are probably repairable.
1. This is a real assembly-language view of binding. This is exactly
what I would have expected in some sort of virtual machine description
of Scheme. This is not what I would call a clean integration of
dynamic binding with Scheme. (If you think it is, try writing
factorial using the primitives you get by substiting ``lexical'' for
``dynamic'' in the proposal.)
Though Scheme has always seemed to be a low-level language to me, this
is really taking it to an extreme in a wrong direction. I'd rather
tell people to figure out how to program without dynamic variables
than provide language features like these.
The next three things I find wrong with the proposal has to do with
dropping the concept of variable from the presentation.
2. The names MAKE-DYNAMIC, DYNAMIC?, DYNAMIC-REF, and DYNAMIC-SET!
refer to procedures that have nothing to do with dynamic anything. If
I MAKE-DYNAMIC, what is dynamic about the thing I get back? What is
dynamic about it is that it is an object that forms part of an
implementation of a dynamic environment. Without a careful description
of dynamic environments, these names are stupid (and they might be
stupid anyway).
3. In this description of DYNAMIC-REF it is not clear what a
dynamic environment is:
``(DYNAMIC-REF dyn) [Procedure]
Return the value of the given dynamic in the current dynamic environment.''
4. Reading up to here in the proposal doesn't prepare me for reading
about binding dynamics to new locations, which is mentioned in the
description of CALL-WITH-DYNAMIC-BINDING:
``(CALL-WITH-DYNAMIC-BINDING dyn obj thunk) [Procedure]
Invoke and return the value of the given thunk in a new, nested dynamic
environment in which the given dynamic has been bound to a new location
whose initial contents are the value obj.''
What does it mean to ``bind a dynamic to a new location''? At this
point it is as sensible as saying ``bind a vector to a new location.''
What is a nested environment?
Well, it would all make sense if the concept of variable weren't swept
under the rug.
5. I've been given enough silly putty to construct a dynamic environment,
but I cannot construct several to be used at the same time.
6. I shudder when I try to imagine the sort of program that would
actually use DYNAMIC?. I suppose it makes implementation easier to
introduce this new type, but what an awful thing. Why not use symbols
for this? These symbols are already distinguished by being in the
dynamic environment.
Here is the start of a rewrite that leverages the current concepts of
variable, binding, environment, and location (By the way, I find
objectionable the use of locations to describe binding and variables,
plus it isn't necessary. On the other hand, it is harmonious with the
assembly-language-like nature of dynamics.):
A dynamic environment is an environment in which objects called
dynamics behave like variables: a dynamic names a location in a
dynamic environment where a value can be stored. Dynamic environments
can be (dynamically) nested. The value of a given dynamic is given by
the (dynamically) innermost dynamic environment with a binding for
that dynamic. At any point there is a current dynamic environment.
The outermost dynamic environment is called the global dynamic
environment.
(MAKE-DYNAMIC obj) [Procedure]
Create and return a new ``dynamic'' whose value in the global dynamic
environment is obj.
(DYNAMIC? obj) [Procedure]
Return true if and only if obj is a dynamic. No object satisfying DYNAMIC?
satisfies any of the other standard type predicates.
(DYNAMIC-REF dyn) [Procedure]
Return the value of the given dynamic in the current dynamic environment.
(DYNAMIC-SET! dyn obj) [Procedure]
Change the value of the given dynamic to obj in the current dynamic
environment. The returned value is unspecified.
(CALL-WITH-DYNAMIC-BINDING dyn obj thunk) [Procedure]
Invoke and return the value of the given thunk in a new, nested
dynamic environment in which the given dynamic has been bound to a new
location whose initial contents are the value obj. This dynamic
environment is nested within the dynamic environment of the invocatio n of
CALL-WITH-DYNAMIC-BINDING. This dynamic environment has precisely the
same extent as the invocation of the thunk and is thus captured by
continuations created within that invocation and re-established by
those continuations when they are invoked.
...
-rpg-
∂07-Dec-89 1522 @zurich.ai.mit.edu,@VIOLA.Reasoning.COM:Gyro@UUCP Dynamic binding -- objection and counter-proposal
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 7 Dec 89 15:22:10 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA12980; Thu, 7 Dec 89 18:16:29 EST
Received: from drums.reasoning.com ([192.5.238.120]) by zurich.ai.mit.edu; Thu, 7 Dec 89 18:15:04 est
Received: from [192.5.238.128] by drums.reasoning.com with SMTP (5.61/25-eef)
id AA06858; Thu, 7 Dec 89 15:15:23 -0800
for RRRS-Authors@zurich.ai.mit.edu
Date: Thu, 7 Dec 89 15:16 PST
From: Gyro@reasoning.com
Subject: Dynamic binding -- objection and counter-proposal
To: pavel.parc@xerox.com
Cc: RRRS-Authors@zurich.ai.mit.edu
In-Reply-To: <8912061827.AA02215@arisia.Xerox.COM>
Message-Id: <19891207231610.4.GYRO@VIOLA.Reasoning.COM>
Date: Wed, 6 Dec 89 10:27:45 -0800
From: pavel.parc@arisia.xerox.com
|--------|-------------------------------------------------------------------|
| | |
| | I object to including a description of dynamic binding, similar |
| X | to that in the recent message to RRRS-Authors, in an appendix to |
| | R4RS. |
| | |
|--------|-------------------------------------------------------------------|
Additional comments:
I've always thought that dynamic binding was an ugly hack. Besides, it
leads to some really weird bugs. Here's my favorite dynamic-binding bug
story:
In the Lisp Machine Chaosnet protocol, opening a file across the net
involves, of course, an exchange of certain information about the file,
some of which (I don't know the details) is in the form of Lisp list
printed into an ASCII string. One machine receives this string from the
other and does, effectively, a READ-FROM-STRING on it. The string
commonly contains the sequence "NIL", which is intended, of course, to
represent the symbol NIL, a.k.a. ().
It is possible to create a package (you all know what packages are,
yes?) that does not inherit from the GLOBAL package; it is also possible
to make that be the default package, by setting the system variable
*PACKAGE*. In fact, I was doing this at one point (I had a good
reason which doesn't matter here).
Here's where the fun comes. If one reads the characters "NIL" when
*PACKAGE* is bound to a package such as I describe, one does not get the
"official" NIL ("the chosen NIL" as Bernie Greenberg used to call it),
but rather a *different* symbol named NIL in said package. So when I
had set *PACKAGE* to such a package, the Chaosnet file code would blow
up because it would be getting these non-NIL symbols in places where it
didn't expect them! This is as obscure and far-flung a
cross-interaction as I've ever seen in the (mostly pretty well
modularized) LispM system.
Now one can point out that the obvious fix is for the Chaosnet code to
bind *PACKAGE* to some package known to be reasonable around the call to
READ. But I contend that a system should be designed so that such bugs
never happen in the first place. And it seems to me that the obvious
mechanism for accomplishing this is only our old friend, lexical
scoping.
Consider this scenario: we have a system function READ-GEN that takes
arguments like BASE, READTABLE (or whatever we call it), etc. and
returns a procedure suitable for binding to READ; i.e. one might write
something like
(let ((read (read-gen 10 scheme-readtable ...)))
(read some-stream))
That is, we make it possible for READ, in different **LEXICAL!!**
contexts, to read using different parameters. Simple enough, yes?
All that remains to make this usable, seems to me, is to give us a way
to establish bindings, such as this one for READ, outside entire sets of
top-level definitions. That, as I understand it, is a primary purpose
of a module system. At least, I hope that when we get around to
designing our module system, we'll support this kind of thing.
(Actually, I think what we really want is generator procedures that
generate entire modules from a single list of parameters; but this
discussion can wait.)
Let's back up for a moment and look at the larger picture. In my
experience as a ZetaLisp/Common Lisp programmer, almost all uses of
special variables fall into the following classes:
-- Those which are never bound except at top level; these are
effectively constants.
-- Those which are bound so frequently that, I would argue the programmer
should have added one or more extra arguments to the relevant
procedures.
-- The kind described above, where one wants to establish certain
default values for parameters of modules; I think all the
language-defined special variables of Common Lisp, for instance,
fall into this category.
Anyone who wants to convince me that dynamic binding should be in a
language will have to show me an example of a case that does not fall in
one of these categories and which I cannot find some other way to handle
that I like better. But I warn you that I've been thinking about this
for a long time and I've never seen one.
-- Scott
∂07-Dec-89 1608 @zurich.ai.mit.edu,@VIOLA.Reasoning.COM:Gyro@UUCP Baby Doe name: CALL-WITH-VALUES --- generator first.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 7 Dec 89 16:08:16 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA13505; Thu, 7 Dec 89 19:04:14 EST
Received: from drums.reasoning.com ([192.5.238.120]) by zurich.ai.mit.edu; Thu, 7 Dec 89 19:02:16 est
Received: from [192.5.238.128] by drums.reasoning.com with SMTP (5.61/25-eef)
id AA06896; Thu, 7 Dec 89 16:02:29 -0800
for rrrs-authors@zurich.ai.mit.edu
Date: Thu, 7 Dec 89 16:03 PST
From: Gyro@reasoning.com
Subject: Baby Doe name: CALL-WITH-VALUES --- generator first.
To: rrrs-authors@zurich.ai.mit.edu
Cc: ramsdell@linus.mitre.org
In-Reply-To: <19891206222957.0.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-Id: <19891208000335.7.GYRO@VIOLA.Reasoning.COM>
The majority -- oops, I mean plurality -- choice was a
pretty close second for me, so I'm not unhappy.
-- Scott
∂07-Dec-89 1819 @zurich.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu records; CALL-WITH-VALUES
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 7 Dec 89 18:18:53 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA14943; Thu, 7 Dec 89 21:15:52 EST
Received: from skinner.cs.uoregon.edu ([128.223.4.13]) by zurich.ai.mit.edu; Thu, 7 Dec 89 21:14:32 est
Received: from spencer.cs.uoregon.edu by skinner.cs.uoregon.edu with SMTP
(5.61.14/IDA-1.2.8) id AA13691; Thu, 7 Dec 89 18:17:12 -0800
Received: by spencer.cs.uoregon.edu; Thu, 7 Dec 89 18:16:08 PST
Date: Thu, 7 Dec 89 18:16:08 PST
From: will@cs.uoregon.edu
Message-Id: <8912080216.AA13274@spencer.cs.uoregon.edu>
To: rrrs-authors@zurich.ai.mit.edu
Subject: records; CALL-WITH-VALUES
The results of my poll are in, and here they are.
No one objected to having a description of the record facility
in an appendix to R4RS, so that will happen.
Here is how people voted on CALL-WITH-VALUES (formerly BABY-DOE):
======================================================================
|
14 | I do not object to describing BABY-DOE in an appendix to
| R4RS, provided its semantics is compatible with the semantics
| I favor.
----------------------------------------------------------------------
|
1 | I object to describing BABY-DOE in an appendix to R4RS.
|
|
======================================================================
|
13 | I do not object to semantics A: "for-effect" continuations
| accept any number of return values.
|
----------------------------------------------------------------------
|
| I object to semantics A but I do not object to semantics B:
| "for-effect" continuations accept either zero or one return
| value.
----------------------------------------------------------------------
|
1 | I object to semantics A and B but I do not object to
| semantics C: "for-effect" continuations accept one return
| value.
----------------------------------------------------------------------
|
1 | None of the above. Either I object to BABY-DOE, or I object
| to Clinger's stupid characterization of the alternative
| semantics for BABY-DOE.
======================================================================
The person who voted "None of the above" volunteered an explanation,
from which I deduce that the person would have voted with the 13 if
not for some confusion over the term "for-effect".
We do not have unanimity here, so our ground rules forbid me to put
CALL-WITH-VALUES into an appendix to R4RS unless the person(s) in the
minority is (are) willing to reconsider his/her/their vote(s). The vote
was pretty clear, though, so those who have been waiting for a consensus
to emerge before implementing multiple values may now be able to proceed.
Peace, Will
∂07-Dec-89 2007 dyb@iuvax.cs.indiana.edu Re: records; CALL-WITH-VALUES
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 7 Dec 89 20:07:08 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA16023; Thu, 7 Dec 89 23:02:39 EST
Received: from iuvax.cs.indiana.edu (iuvax.cs.indiana.edu) by zurich.ai.mit.edu; Thu, 7 Dec 89 23:01:17 est
Message-Id: <8912080401.AA08895@zurich.ai.mit.edu>
Received: by iuvax.cs.indiana.edu
Date: Thu, 7 Dec 89 23:01:12 -0500
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
To: will@cs.uoregon.edu
Subject: Re: records; CALL-WITH-VALUES
Cc: rrrs-authors@zurich.ai.mit.edu
I am sorry for not saying so earlier, but I do object to putting the
record proposal in an appendix to R4RS. For some reason, I was waiting
for a formal "vote" to be called as for the other two issues (baby doe
and dynamics). I do not feel that it is in the spirit of our agreement
not to make substantive changes to the report via email. Furthermore,
I object to the abstraction-breaking elements of the record proposal.
They should be a part of the programming environment, not built into
the language. I seem to remember that this concern was voiced by one
or more people when the proposal was first made, and that there was no
resolution. It is an important enough issue that I think it should be
discussed at greater length before it is added to the report, even as
an appendix.
Kent
∂08-Dec-89 1028 andy@neon.stanford.edu The many faces of NIL, or special cases have to be handled specially.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 8 Dec 89 10:28:05 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA24806; Fri, 8 Dec 89 13:16:57 EST
Received: from Neon.Stanford.EDU ([36.8.0.158]) by zurich.ai.mit.edu; Fri, 8 Dec 89 13:15:39 est
Received: by Neon.Stanford.EDU (5.61/25-eef) id AA11514; Fri, 8 Dec 89 10:16:09 -0800
Date: Fri, 8 Dec 89 10:16:09 -0800
From: Andy Freeman <andy@neon.stanford.edu>
Message-Id: <8912081816.AA11514@Neon.Stanford.EDU>
To: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Gyro@reasoning.com's message of Thu, 7 Dec 89 15:16 PST <19891207231610.4.GYRO@VIOLA.Reasoning.COM>
Subject: The many faces of NIL, or special cases have to be handled specially.
>Now one can point out that the obvious fix is for the Chaosnet code to
>bind *PACKAGE* to some package known to be reasonable around the call to
>READ. But I contend that a system should be designed so that such bugs
>never happen in the first place. And it seems to me that the obvious
>mechanism for accomplishing this is only our old friend, lexical
>scoping.
I ran into a similar problem, but I think the correct solution lies in
print. In the situation described, the program was correct iff the
printer and reader were using compatible packages, as the default
package says how to interpret symbol shorthand, that is, symbol names
that don't include their package. In the case I ran into, and it
seems this case as well, print assumed that NIL always meant
global::nil, so it didn't bother to check whether it did in its
*PACKAGE*. (Of course, if it had printed () instead, all would have
been okay, but there are other special symbols that don't have an
unambiguous shorthand in non-symbol-name syntax.)
Getting back to the reason for the tangent, the discussion of dynamics
(that name grates on me too), I think that rpg's message brings up
something important. I think the dynamic proposals have used the
assembly-language-style wall to hide something. I think that
something is something about the nature of control-flow, as dynamics
are fundamentally a tool for associating values with control, and
control has been something of a second-class citizen up until now.
Can the first-class environment people help here?
BTW - I like much of rpg's proposal, but I don't like the idea that
dynamics can only be created in the global environment. To that end,
I'd like to see:
(CALL-WITH-DYNAMIC obj thunk) [Procedure]
Invoke thunk in a new dynamic environment that is nested within the
current dynamic environment and contains a new dynamic whose initial
contents are the value obj. The thunk is called with that dynamic as
its argument. This dynamic environment has precisely the same extent
as the invocation of the thunk and is thus captured by continuations
created within that invocation and re-established bythose
continuations when they are invoked.
make-dynamic makes me a bit uneasy. I think I'd prefer something
along the lines of a top-level define. (Perhaps that analogy can be
stretched to include a meaning for define-dynamics at other levels.)
-andy
∂08-Dec-89 1358 @zurich.ai.mit.edu,@VIOLA.Reasoning.COM:Gyro@UUCP Dynamic binding, cont.: modularity issues
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 8 Dec 89 13:58:38 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA28260; Fri, 8 Dec 89 16:55:02 EST
Received: from drums.reasoning.com ([192.5.238.120]) by zurich.ai.mit.edu; Fri, 8 Dec 89 16:53:40 est
Received: from [192.5.238.128] by drums.reasoning.com with SMTP (5.61/25-eef)
id AA08248; Fri, 8 Dec 89 13:54:02 -0800
for rrrs-authors@zurich.ai.mit.edu
Date: Fri, 8 Dec 89 13:55 PST
From: Gyro@reasoning.com
Subject: Dynamic binding, cont.: modularity issues
To: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: <8912081816.AA11514@Neon.Stanford.EDU>
Message-Id: <19891208215506.9.GYRO@VIOLA.Reasoning.COM>
Date: Fri, 8 Dec 89 10:16:09 -0800
From: Andy Freeman <andy@neon.stanford.edu>
>Now one can point out that the obvious fix is for the Chaosnet code to
>bind *PACKAGE* to some package known to be reasonable around the call to
>READ. But I contend that a system should be designed so that such bugs
>never happen in the first place. And it seems to me that the obvious
>mechanism for accomplishing this is only our old friend, lexical
>scoping.
I ran into a similar problem, but I think the correct solution lies in
print. In the situation described, the program was correct iff the
printer and reader were using compatible packages, [...]
You've missed the point. Certainly you can see this particular example
(and all the others I could come up with) as a special case, but I claim
that it is not one; that the use of dynamic binding to control various
parameters of a system is inherently destructive to modularity, and for
just the reason that this example shows.
Let me state the issue more generally. Consider any two functions A
and B such that A calls B, either directly or indirectly through a chain
of other functions. Suppose that B references special variable *X*, and
that *X* is not bound anywhere between A and the reference to it in B.
Then the value of *X* when A is called affects the computation A
performs; so *X* is really a parameter of A, albeit a hidden one: one
that does not appear in A's parameter list.
I understand that this is precisely what people who want special
variables think they want: parameters to procedures that they don't have
to supply a value for in every call. That's a perfectly fine goal; the
argument we are having is over where those values should come from. The
usual pattern of Lisp thought is that they should be supplied by the
*dynamic* environment at the point of the procedure call. What I am
trying, perhaps clumsily as yet, to say is that while that approach
works well enough for programming in the small, it starts to cause
problems in large systems; but that supplying them *lexically*, in a
manner such as I have described, avoids those problems.
While not everyone is used to thinking in terms of the demands of
programming in the large, and so perhaps not everyone will readily
understand my argument, I did have the impression that Pavel in
particular (whose dynamic binding proposal we are considering) is
sensitive to the kind of issues I am raising. I recall him being an
outspoken opponent of first-class environments, for instance, on grounds
of the dangers they pose to modularity. I hope he will take the time to
consider carefully what I am saying. In fact, Pavel, as strongly as I
feel that R↑nRS Scheme should not have dynamic binding, I feel even more
strongly that Scheme Cedar should not have it, or I would anyhow if I
were involved in your project.
By the way, I consider it not an accidental but actually quite a deep
property of my proposed substitute for special variables that it is part
of a (hypothesized) module system, and that its use in a program will
require appropriate organization of that program into modules. That's
part of the point.
I should add that these modularity issues are not the sole kind of
reason I have for objecting to the inclusion of any sort of dynamic
binding. I don't like the consequences for the implementation either.
I suppose my biggest objection is that the mere existence of dynamic
binding, even when I'm not using it, still adds a certain amount of
overhead to CALL/CC and invocation of the resulting continuations: the
system, at the very least, has to check to see that there are no dynamic
bindings to be saved or restored. In practice, an implementation will
probably allocate a 0-length vector in the heap to store these 0
bindings in. Aha, what's worse, if I write program X and never use
dynamic binding, so I assume that continuation capture and invocation is
fast and I use it heavily, and then someone installs program X in a
Scheme along with somebody else's program Y that binds 100 dynamics (for
its own reasons) and then calls X, every continuation X captures will be
loaded down with these 100 dynamic bindings, which will be waste both
CPU and memory. Even if it's 10 instead of 100, the effect could be
substantial.
-- Scott
∂08-Dec-89 1701 @zurich.ai.mit.edu,@VIOLA.Reasoning.COM:Gyro@UUCP Dynamic binding implementation issues
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 8 Dec 89 17:01:52 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA00624; Fri, 8 Dec 89 19:58:13 EST
Received: from drums.reasoning.com ([192.5.238.120]) by zurich.ai.mit.edu; Fri, 8 Dec 89 19:56:54 est
Received: from [192.5.238.128] by drums.reasoning.com with SMTP (5.61/25-eef)
id AA08387; Fri, 8 Dec 89 16:57:18 -0800
for RRRS-Authors@Zurich.AI.MIT.EDU
Date: Fri, 8 Dec 89 16:58 PST
From: Gyro@reasoning.com
Subject: Dynamic binding implementation issues
To: RRRS-Authors@zurich.ai.mit.edu
In-Reply-To: <8912082232.AA00730@Neon.Stanford.EDU>
Message-Id: <19891209005820.2.GYRO@VIOLA.Reasoning.COM>
Date: Fri, 8 Dec 89 14:32:28 -0800
From: Andy Freeman <andy@Neon.Stanford.EDU>
Deep binding solves your objection. One load/store to invoke a
continuation is not a significant cost. Nothing else gets copied or
done unless/until you use them.
Shallow binding won't work on multiprocessor architectures and
isn't necessarily faster on uniprocessors even if continuations
aren't first-class citizens.
Okay, fair point: the force of my implementation-related objections is
somewhat reduced by the fact that deep-binding implementations are
possible and would not suffer the problems I mention. I will grant that
the implementation issues I raise are really arguments against shallow-
bound implementations. However, I quote an earlier message of Pavel's:
-- Given ``dynamic-wind'', a portable shallow-binding implementation of the
proposal can be written for all single-processor implementations of Scheme.
It was suggested at the BASH meeting that something like this be done and
placed in the library. As stated in earlier messages, multiprocessor
implementations will have to implement it more primitively; Jinx has
pointed out, however, that two simple procedures for accessing the
process-specific dynamic environment suffice.
It's clearly the sense of the community at the moment that the default
uniprocessor implementation use shallow binding. If I can't talk people
out of dynamic binding entirely, perhaps I can succeed in making
shallow-bound implementations unpopular.
My modularity-based objections to any form of dynamic binding stand.
-- Scott
∂11-Dec-89 1243 andy@neon.stanford.edu Modules don't provide the functionality of dynamic binding
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 11 Dec 89 12:43:47 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA02615; Mon, 11 Dec 89 15:36:17 EST
Received: from Neon.Stanford.EDU ([36.8.0.158]) by zurich.ai.mit.edu; Mon, 11 Dec 89 15:34:33 est
Received: by Neon.Stanford.EDU (5.61/25-eef) id AA21105; Mon, 11 Dec 89 12:34:47 -0800
Date: Mon, 11 Dec 89 12:34:47 -0800
From: Andy Freeman <andy@neon.stanford.edu>
Message-Id: <8912112034.AA21105@Neon.Stanford.EDU>
To: rrrs-authors@zurich.ai.mit.edu, Gyro@reasoning.com
Subject: Modules don't provide the functionality of dynamic binding
Scott recently touted a flexible module facility as a substitute for
dynamic binding. He also divided uses of dynamic binding into three
categories, and claimed that modules worked "better", especially for
large programs, in those cases. In this message, I hope to convince
you that using modules to replace dynamic binding in at least one of
those cases requires dynamics.... (This is not intended as an
argument against a flexible module facility. I think it's a wonderful
tool for other problems.)
Scott said that dynamics were often used to pass arguments indirectly;
the simple case is that A calls B and B calls C, but A wants to
provide input to C that it doesn't want to pass through B. I agree.
Scott's proposed solution was for A to construct (using the module
facility), a custom version of C that has the arguments that A wants
to provide and have B call that procedure. The problem with that
is telling B which C to call.
To illustrate that, let's look at a more complex example. As above, A
wants to call C indirectly through B, without letting B see all of C's
input. (I guess I should clarify what "see" means. It means that one
can examine B's text to determine whether or not it looks at the
variable in question. If dynamics are data objects, this doesn't
work, but ....) Since we're concerned with programming in the large,
let's include A', which also wants to call C indirectly through B, and
A' wants to provide the same input to C that A did. (In a related
case, A and A' are providing default values for different input to C.)
If A and A' construct their own versions (using the module system) of
C, then they have to tell B to call the right one. One way is for
them to pass it. This "works", but misses the point and is awkward
for more complex examples. The alternative is for them to redefine
C's (global to B) definition. Maintaining that redefinition
correctly, when B is not defined within A, requires simulating
dynamics....
-andy
∂11-Dec-89 1521 KMP@stony-brook.scrc.symbolics.com Dynamic binding
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 11 Dec 89 15:20:59 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA06191; Mon, 11 Dec 89 18:16:33 EST
Received: from STONY-BROOK.SCRC.Symbolics.COM (stony-brook.scrc.symbolics.com) by zurich.ai.mit.edu; Mon, 11 Dec 89 18:15:13 est
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 705982; 11 Dec 89 18:15:39 EST
Date: Mon, 11 Dec 89 18:15 EST
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Subject: Dynamic binding
To: RRRS-Authors@zurich.ai.mit.edu
Cc: KMP@stony-brook.scrc.symbolics.com
Message-Id: <19891211231534.8.KMP@BOBOLINK.SCRC.Symbolics.COM>
I don't have time to be involved in this discussion in an ongoing fashion,
so I'm just going to do a small "core dump" of my position on the subject
in reply to Gyro's message (and in support of Andy's reply):
"Dynamic Binding" is not a problematic linguistic artifact which we
can dispense with by voting it out. Rather, it is a problematic
real-world artifact which cannot be eliminated by vote.
It is like the abstract of the "immovable object" and the "unstoppable"
force. Both are useful to reason about in the abstract--in fact, so useful
that you would not want to a priori rule out the use of either even though
they don't do so well when combined.
The ability to write a program whose contract absolutely cannot be
overridden is useful. The ability to write a program which can absolutely
always override another's contract is also useful. The best we can do is
provide primitives which give people the ability to say which they intend.
The problems which lead to the use of dynamic binding are real. They
aren't just caused by someone misunderstanding the potential ill effects
of dynamic binding. If the issue were only "modules" or "lexical
scoping", then people would just use those because they're already
(effectively) in Scheme. The problem isn't that we have a primitive
sitting around which no one uses, but rather that there's a certain
feature which whether we provide it or not, keeps coming up in
discussion. There must be something more than mass ignorance which
makes this happen.
I believe there are uses which involve a legitimate need to factor
dynamic, environmental information into a program. As Andy suggests,
if you exclude this capability at the language level, you just force the
person to simulate it using the language.
The situation is analogous to the naming of the "funny little thing at
the end of a shoelace that keeps it from fraying". I hear there's a
name for the thing, but the fact is that it's not in the standard
dialect which most people speak, and it doesn't matter because most
people can simulate its effect by just composing words in the given
language. But if the word "home" had been omitted, that would be a bad
thing linguistically because although one could talk about "the funny
little wooden or brick (or cardboard) structure that you come home to
every night", it would not be fun to have book titles and punchy little
phrases like "there's no place like the funny little wooden or brick (or
cardboard) structure that you come home to every night". Usage patterns
tell you what needs to be constructable, what needs to be present
primitively, and what doesn't need to be there at all.
As with the GOTO statement or an iteration facility, dynamic binding is
a thing about which people like to speak and reason. Language designers
may choose to support such speech at the languistic level or not, as
they choose, but that only affects how concepts are expressed verbally--it
does not dictate which concepts are permitted.
No language can optimize all things. A primary goal of a language
should be to optimize those things which people often say. Another
is to make the common things efficient. If you optimize for the wrong
set of commonly-used expressions, people will resent the fact that you have
made their speech patterns too clumsy or their code too slow, and they will
seek another language.
In the case of Dynamic Binding, it's tough to implement this correctly
or efficiently in user code (at least without DYNAMIC-WIND, and maybe
even then), so that's another argument for having it.
I'm not definitely of the opinion that dynamic bind should be in scheme.
But I'm definitely of the opinion that dynamic bind should definitely
not definitely not be in scheme. [Yes, I double-checked, there are no
spurious words in the previous sentence.] That is, in Kripke's
terminology, it may be "true" that dynamic bind doesn't belong in
Scheme, but it is not "necessarily true" that it doesn't belong. Any
decision to leave it out must be done on the basis of reasoned debate,
probably about statistical need, not on the basis of any claims of
inherent truth.
∂11-Dec-89 1645 @zurich.ai.mit.edu,@ZERMATT.LCS.MIT.EDU:ziggy@HX.LCS.MIT.EDU RE: dynamic binding
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 11 Dec 89 16:45:35 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA07421; Mon, 11 Dec 89 19:39:06 EST
Received: from ZERMATT.LCS.MIT.EDU (zermatt.lcs.mit.edu) by zurich.ai.mit.edu; Mon, 11 Dec 89 19:37:25 est
Received: from HX.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via INTERNET with SMTP id 317436; 11 Dec 89 19:36:26 EST
Received: by hx.LCS.MIT.EDU (5.51/4.7); Mon, 11 Dec 89 19:32:19 EST
Date: Mon, 11 Dec 89 19:32:19 EST
From: ziggy@hx.lcs.mit.edu (Michael R. Blair)
Message-Id: <8912120032.AA24098@hx.LCS.MIT.EDU>
To: rrrs-authors%zurich.ai.mit.edu@zermatt.ai.mit.edu
Subject: RE: dynamic binding
I have tried a few times to implement a nice error handling mechanism in
Scheme ... modeled losely after exception signalling in Mesa/CLU/Ada.
I have wanted FLUID-LET... one that dynamic unwinds so when an ABORT key
is pressed I don;t find myself in an inconsistent state.
I cannot think of an elegant way to implement such a dynamic mechanism
without using REAL dynamic binding. Call me shallow, but I cannot imagine
how modules would help this... and I think exception handing enhances
modularity and is essential for programming in the large.
~Zigroid
P.S. Please fix me if I'm broken... "proof by lack of imagination" is not
very compelling, I realize.
∂11-Dec-89 2112 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #256
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 11 Dec 89 21:11:57 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA11965; Tue, 12 Dec 89 00:11:00 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Tue, 12 Dec 89 00:09:38 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa06595;
12 Dec 89 0:07 EST
Date: 12 DEC 89 00:08:16 EST
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.lcs.mit.edu>
Subject: Scheme Digest #256
To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Message-Id: <8912120008.aa06595@mintaka.lcs.mit.edu>
Scheme Digest #256 12 DEC 89 00:08:16 EST
Today's Topics:
continuation based error handling
----------------------------------------------------------------------
Date: 11 Dec 89 22:59:24 GMT
From: Eric Raible <amelia!orville.nas.nasa.gov!raible@AMES.ARC.NASA.GOV>
Subject: continuation based error handling
Message-Id: <4169@amelia.nas.nasa.gov>
It seems to me that it ought to be possible to implement a somewhat
portable error handling facility using call/cc.
I'd appreciate comments and/or code.
------------------------------
End of Scheme Digest
********************
∂12-Dec-89 0032 @zurich.ai.mit.edu,@VIOLA.Reasoning.COM:Gyro@UUCP Modules vs. dynamic binding
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 12 Dec 89 00:31:56 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA13531; Tue, 12 Dec 89 03:27:06 EST
Received: from drums.reasoning.com ([192.5.238.120]) by zurich.ai.mit.edu; Tue, 12 Dec 89 03:25:50 est
Received: from [192.5.238.128] by drums.reasoning.com with SMTP (5.61/25-eef)
id AA00513; Tue, 12 Dec 89 00:26:09 -0800
for rrrs-authors@zurich.ai.mit.edu
Date: Tue, 12 Dec 89 00:27 PST
From: Gyro@reasoning.com
Subject: Modules vs. dynamic binding
To: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: <8912112034.AA21105@Neon.Stanford.EDU>
Message-Id: <19891212082737.2.GYRO@VIOLA.Reasoning.COM>
Date: Mon, 11 Dec 89 12:34:47 -0800
From: Andy Freeman <andy@neon.stanford.edu>
Scott said that dynamics were often used to pass arguments indirectly;
the simple case is that A calls B and B calls C, but A wants to
provide input to C that it doesn't want to pass through B. I agree.
Scott's proposed solution was for A to construct (using the module
facility), a custom version of C that has the arguments that A wants
to provide and have B call that procedure. The problem with that
is telling B which C to call.
If A and A' construct their own versions (using the module system) of
C, then they have to tell B to call the right one. One way is for
them to pass it. This "works", but misses the point and is awkward
for more complex examples. The alternative is for them to redefine
C's (global to B) definition. Maintaining that redefinition
correctly, when B is not defined within A, requires simulating
dynamics....
I think you're still missing the point, Andy. The possibility you
overlook is that A can have one instance of B which calls C, and A' can
have another instance, B', which calls C'. Or, as you point out, B can
accept an instance of C as an argument. My claim is that these two
choices are all one needs to elegantly structure any program.
-- Scott
∂12-Dec-89 0207 @zurich.ai.mit.edu,@VIOLA.Reasoning.COM:Gyro@UUCP Dynamic binding
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 12 Dec 89 02:07:31 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA14093; Tue, 12 Dec 89 05:00:17 EST
Received: from drums.reasoning.com ([192.5.238.120]) by zurich.ai.mit.edu; Tue, 12 Dec 89 04:58:51 est
Received: from [192.5.238.128] by drums.reasoning.com with SMTP (5.61/25-eef)
id AA00599; Tue, 12 Dec 89 01:59:09 -0800
for RRRS-Authors@zurich.ai.mit.edu
Date: Tue, 12 Dec 89 02:00 PST
From: Gyro@reasoning.com
Subject: Dynamic binding
To: RRRS-Authors@zurich.ai.mit.edu
In-Reply-To: <19891211231534.8.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-Id: <19891212100037.3.GYRO@VIOLA.Reasoning.COM>
Date: Mon, 11 Dec 89 18:15 EST
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
"Dynamic Binding" is not a problematic linguistic artifact which we
can dispense with by voting it out. Rather, it is a problematic
real-world artifact which cannot be eliminated by vote.
The problems which lead to the use of dynamic binding are real. They
aren't just caused by someone misunderstanding the potential ill effects
of dynamic binding. If the issue were only "modules" or "lexical
scoping", then people would just use those because they're already
(effectively) in Scheme. The problem isn't that we have a primitive
sitting around which no one uses, but rather that there's a certain
feature which whether we provide it or not, keeps coming up in
discussion. There must be something more than mass ignorance which
makes this happen.
I'm afraid I don't accept this argument. As language designers, we all
know of features that users generally think they want, but which we know
they shouldn't have, because a) if they use them, they wind up writing
programs that are inefficient/ hard to compile/ poorly structured/
whatever, AND b) there are better ways to do the job. (FEXPRs come
readily to mind as an example.) (Clearly we require both (a) and (b) to
be true before we decline to provide some feature; when a feature is
dangerous but necessary, as of course often happens, we provide it and
try to teach people how to handle it.)
I believe that the apparent desirability of dynamic binding is a
concomitant of a particular way of organizing programs in the large, the
only way that mainstream Lisps (sans object-oriented extensions) have
historically provided, viz., as a homogeneous collection of definitions
in a single top-level environment. I believe that if that is how one
thinks of a program, there are indeed certain problems that can be
conveniently solved only by having available, or simulating, dynamic
binding. I think that that is an artifact of the program organization,
and not an essential property of any computation. I believe that given
Scheme with a properly designed module facility, it would be possible to
write a complex software system, on the order e.g. of the Lisp Machine
system, and to do it quite elegantly and efficiently without once using
*or simulating* dynamic binding.
As with the GOTO statement or an iteration facility, dynamic binding is
a thing about which people like to speak and reason. Language designers
may choose to support such speech at the languistic level or not, as
they choose, but that only affects how concepts are expressed verbally--it
does not dictate which concepts are permitted.
But we Schemers have abandoned GOTO in favor of the procedure call in
tail-recursive position, and rightly so, the idea being that we slightly
modify a familiar and well-liked concept, the procedure call, and
discover that lo and behold, we simply don't need GOTO anymore; we have
something which covers all the uses for which we would have wanted it,
and does many more things we couldn't do nearly so elegantly before. I
believe this is a similar situation.
No language can optimize all things. A primary goal of a language
should be to optimize those things which people often say. Another
is to make the common things efficient. If you optimize for the wrong
set of commonly-used expressions, people will resent the fact that you have
made their speech patterns too clumsy or their code too slow, and they will
seek another language.
And another goal is to encourage good structure. It's one that's less
widely appreciated, since a taste for it requires some experience with
large (or at least medium-large) programs, but for some of us it's very
important.
I hasten to add that I don't think the style I advocate will turn out to
be clumsy or convoluted; and I think it will bring a gain in efficiency,
not a loss. There is no question that it is a different style from the
one Lisp programmers are used to, and that changing over to it will
initially require some mental gymnastics (not any greater than, and in
fact similar to, those required to learn object-oriented programming).
Whether we as the designers of Scheme want to force people to make that
leap is another question entirely (more on which below).
I'm not definitely of the opinion that dynamic bind should be in scheme.
But I'm definitely of the opinion that dynamic bind should definitely
not definitely not be in scheme. [Yes, I double-checked, there are no
spurious words in the previous sentence.] That is, in Kripke's
terminology, it may be "true" that dynamic bind doesn't belong in
Scheme, but it is not "necessarily true" that it doesn't belong. Any
decision to leave it out must be done on the basis of reasoned debate,
probably about statistical need, not on the basis of any claims of
inherent truth.
But as I point out, we omit FEXPRs and GOTO on the basis of analysis,
not statistics.
Listen, I don't want to sound rabid about this. Let me add that I know
perfectly well that I'm leaning against the wind, that my viewpoint is
highly unorthodox within the Lisp community, and that I'm not
emotionally attached to swaying the opinion of the community on the
matter. (I'm certainly not inclined to block consensus, should it come
to that.) Nevertheless, you did ask my opinion; so I thought, What the
hell, I think I have an important point here, let's see if I can
communicate it.
I think the final resolution of the matter may be like this. I am
absolutely convinced that for the purposes for which I want a
programming language, it shouldn't provide dynamic binding. What is not
so clear is that my purposes and goals for a language are the same as
those of the Scheme community; in fact, they probably aren't. So it
could conceivably come to pass that many or most of you understand the
point I am making without agreeing that it is applicable to Scheme in
particular. Specifically, as I mentioned above, I would constrain
people's programming styles in a particular way (which I happen to think
leads to better programs and better thinking about programs). The
community could well decide that it is more interested in supporting a
variety of programming styles, and not so interested in teaching
stylistics. (I observe that good programmers-in-the-large are far rarer
and more valuable than good programmers-in-the-small, and think we
should do anything we can to encourage the latter to grow into the
former.)
-- Scott
∂12-Dec-89 0220 @zurich.ai.mit.edu,@VIOLA.Reasoning.COM:Gyro@UUCP RE: dynamic binding
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 12 Dec 89 02:20:26 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA14205; Tue, 12 Dec 89 05:14:14 EST
Received: from drums.reasoning.com ([192.5.238.120]) by zurich.ai.mit.edu; Tue, 12 Dec 89 05:12:55 est
Received: from [192.5.238.128] by drums.reasoning.com with SMTP (5.61/25-eef)
id AA00659; Tue, 12 Dec 89 02:13:14 -0800
for RRRS-Authors@zurich.ai.mit.edu
Date: Tue, 12 Dec 89 02:14 PST
From: Gyro@reasoning.com
Subject: RE: dynamic binding
To: RRRS-Authors@zurich.ai.mit.edu
In-Reply-To: <8912120032.AA24098@hx.LCS.MIT.EDU>
Message-Id: <19891212101439.4.GYRO@VIOLA.Reasoning.COM>
Date: Mon, 11 Dec 89 19:32:19 EST
From: ziggy@hx.lcs.mit.edu (Michael R. Blair)
I have tried a few times to implement a nice error handling mechanism in
Scheme ... modeled losely after exception signalling in Mesa/CLU/Ada.
Interesting... as I recall, exception handler scoping in CLU is lexical,
and I would be surprised if that were not also the case in Mesa and Ada.
No, wait, this is coming back to me. Exception handler scoping in CLU
is kinda weird. The scope of a condition handler is the body of the
procedure that defines it (do I correctly recall that handlers can be
set up only for entire procedures, not for parts thereof?) and all the
procedures it calls *directly*, but *not*, curiously enough, the
procedures it calls indirectly (i.e. those its callees call). Do I have
this right? Where did I put that old CLU manual anyway?...
I have wanted FLUID-LET... one that dynamic unwinds so when an ABORT key
is pressed I don;t find myself in an inconsistent state.
I cannot think of an elegant way to implement such a dynamic mechanism
without using REAL dynamic binding. Call me shallow, but I cannot imagine
how modules would help this... and I think exception handing enhances
modularity and is essential for programming in the large.
I agree that exception handling is essential.
P.S. Please fix me if I'm broken... "proof by lack of imagination" is not
very compelling, I realize.
Um, I need a little more specific a scenario to respond to. What did
you want FLUID-LET for, exactly?
-- Scott
∂12-Dec-89 0343 cph@zurich.ai.mit.edu Modules vs. dynamic binding
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 12 Dec 89 03:43:23 PST
Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.0/AI-4.10) id AA14876; Tue, 12 Dec 89 06:40:10 EST
Received: from localhost by zurich.ai.mit.edu; Tue, 12 Dec 89 06:38:57 est
Date: Tue, 12 Dec 89 06:38:57 est
From: cph@zurich.ai.mit.edu (Chris Hanson)
Message-Id: <8912121138.AA10395@zurich.ai.mit.edu>
To: Gyro@reasoning.com
Cc: rrrs-authors@zurich.ai.mit.edu
Subject: Modules vs. dynamic binding
Date: Thu, 7 Dec 89 15:16 PST
From: Gyro@Reasoning.COM
Consider this scenario: we have a system function READ-GEN that takes
arguments like BASE, READTABLE (or whatever we call it), etc. and
returns a procedure suitable for binding to READ; i.e. one might write
something like
(let ((read (read-gen 10 scheme-readtable ...)))
(read some-stream))
That is, we make it possible for READ, in different **LEXICAL!!**
contexts, to read using different parameters. Simple enough, yes?
All that remains to make this usable, seems to me, is to give us a way
to establish bindings, such as this one for READ, outside entire sets of
top-level definitions. That, as I understand it, is a primary purpose
of a module system. At least, I hope that when we get around to
designing our module system, we'll support this kind of thing.
(Actually, I think what we really want is generator procedures that
generate entire modules from a single list of parameters; but this
discussion can wait.)
Scott, this technique you propose is a useful one, but I don't believe
it provides a replacement for dynamic binding. The problem with the
technique is that the procedure `read' cannot be embedded in another
program unless the embedding program is also parameterized in a
similar way (by "embedded" I mean that the variable `read' is bound in
some closing environment of the embedding program).
To properly take advantage of this technique (as you point out), every
embedding program must be parameterized, and furthermore the
parameters of the embedded program must also be parameters of the
embedding program. That's the only way we can specialize programs
_after_ they've been built and embedded in other programs. Ultimately
this means that every time a new program is built it must be
specialized with all of the "dynamic" variables of all of the
procedures that it calls before it can be run. Clearly nobody wants
to write all of that specialization by hand, and yes, all this "late
binding" can be hidden by a module system; but what about the program
that occasionally specializes itself as it runs? Does the module
system know how to create new programs on the fly, or is it restricted
to describing more static relationships? (I'm used to thinking of a
"module system" as something that describes the static relationships
of a program's parts, not their dynamic relationships -- although if
there's a strict formal definition of "module system" I'm unaware of
it.) Ultimately this "module system" becomes an integral part of the
language -- it has introduced a new kind of binding with "dynamic"
characteristics. What are the semantics of this binding? Is it
different from what we now think of as "dynamic binding"? Is this
really a new idea or just a new implementation of an old idea?
Another solution to this problem was invented by John Lamping a few
years ago: he introduced another kind of variable that could be bound
after the program was constructed. These variables can be considered
to be "holes" in the program, which can be filled in at any time by a
virtual-copy process that produced a new program in which a particular
set of "holes" was filled. Program fragments can be combined into
larger program fragments, independent of whether they have "holes";
"matching holes" in two program fragments become identified in the
combined fragment. With this solution, `read' would have such a
variable for its radix, and this variable would be unspecified when
`read' was defined. You could then embed `read' in some big program,
and just before you were ready to run it, you could specialize the
embedding program with the desired radix.
Lamping's solution has some major advantages over what you propose:
* The embedding program doesn't have to know anything about what
"holes" `read' has.
* The values being supplied to the "holes" can be collected
together in an environment and supplied all at once. A "default
environment" can easily be created, and the user can override
particular bindings in that environment by shadowing.
* It is clearly a change to the language itself rather than a
system that at least nominally is not a fundamental part of the
language.
The problem with this solution is that it is a _major_ language
change; it affects the semantics at a very basic level.
But are either of these solutions really so different from dynamic
binding? You claim that dynamic binding is destructive to modularity,
but with the implementation proposed by Pavel the designer must
clearly state the intention that a particular parameter may be
dynamically bound, so the parameter is clearly part of the program's
abstraction boundary (if you can get your hands on it). The only
other way I can imagine harming modularity is if the user dynamically
binds some procedure's variable, then calls an embedding program which
uses that procedure in two different contexts, only one of which would
like to see the dynamic binding; this would be an inadvertent capture.
But I think this could happen with your solution or with Lamping's
solution as well; the main advantage of your solution here is that the
explicitness of the parameter binding forces the designer to see that
the procedure is being used in two different contexts. A good
designer will see that anyway, because the abstraction spec of the
procedure will contain the information.
I think this topic is an interesting one that falls between the
cracks: it's a little too dynamic for modules, and not dynamic enough
for procedural arguments. I'd like to see some work done on
understanding this; I suspect that Lamping's work is a good first step
(implementing his language efficiently is quite challenging).
On the other hand, I have a strong feeling that dynamic binding is the
best solution to this problem for Scheme -- a better solution may
require changes that are fundamental enough that the result may no
longer be "Scheme-like".
∂12-Dec-89 0916 RPG@sail.stanford.edu re: Dynamic binding
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 12 Dec 89 09:16:14 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA18356; Tue, 12 Dec 89 12:13:22 EST
Received: from SAIL.Stanford.EDU (sail.stanford.edu) by zurich.ai.mit.edu; Tue, 12 Dec 89 12:11:57 est
Message-Id: <oJ85Z@SAIL.Stanford.EDU>
Date: 12 Dec 89 0912 PST
From: Dick Gabriel <RPG@sail.stanford.edu>
Subject: re: Dynamic binding
To: Gyro@reasoning.com, RRRS-Authors@zurich.ai.mit.edu
[In reply to message from Gyro@reasoning.com sent Tue, 12 Dec 89 02:00 PST.]
Gyro writes:
But we Schemers have abandoned GOTO in favor of the procedure call in
tail-recursive position, and rightly so, the idea being that we slightly....
Not actually: we have only made it harder to spell and split its name
in two parts, one of which the user gets to choose. It is now called
call-with-current-continuation/<a name of your choosing here>.
[No smiley face]
-rpg-
∂12-Dec-89 1041 @zurich.ai.mit.edu,@MC.lcs.mit.edu,@ZERMATT.lcs.mit.edu:ziggy@hx.lcs.mit.edu RE: dynamic bindng
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 12 Dec 89 10:41:13 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA19873; Tue, 12 Dec 89 13:38:10 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Tue, 12 Dec 89 13:36:55 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa23878;
12 Dec 89 13:22 EST
Received: from ZERMATT.LCS.MIT.EDU (CHAOS 17316) by MC.LCS.MIT.EDU; 12 Dec 89 13:17:05 EST
Received: from HX.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via INTERNET with SMTP id 317609; 12 Dec 89 13:15:25 EST
Received: by hx.LCS.MIT.EDU (5.51/4.7); Tue, 12 Dec 89 13:10:43 EST
Date: Tue, 12 Dec 89 13:10:43 EST
From: "Michael R. Blair" <ziggy@hx.lcs.mit.edu>
Message-Id: <8912121810.AA01118@hx.LCS.MIT.EDU>
To: gyro%reasoning.com@zermatt.lcs.mit.edu
Subject: RE: dynamic bindng
Cc: rrrs-authors@zermatt.lcs.mit.edu
I use FLUID-LET to dynamically rebind environmnent variables, like
*debugging?* *alpha-rename* *found-an-error?*... things that look like
they could be arguments but which would have to be included in every
procedure of a complex module so the info could propagate and percolate
to those few procedures which actually use them.
If you view a module as an object in the Object-Oriented sense, these
effectively correspodn to modifiable instance variables.
Again, I use FLUID-LET (which I hope uses dynamic-unwind) to reset
my state to a sane default if/when I blow out into the debugger
and abort.
By the way, what I was alluding to whith my reference to exception
handling was that something like (SIGNAL over-flow "Overflow on
arg to SQUARE" arg) will invoke something which depends non who the
dynamic caller to SQUARE was. It involves dynamically binding a
handler that the callee invokes upon error (default is "the no handler
handler"). This is the classic way that exception handling is presented
in a denotational sematics setting (namely, bind a handler continuation
in a dynamic environmnetyλ.
[Sorry about all the typos... the blasted machine I am hacking on does
not understand my terminal type so I cannot use EMACS or even backspace
to fix myself. We lowly gradual students sometimes have to make do with
losing eqipment in public areas.]
∂12-Dec-89 1209 gls@think.com Dynamic binding
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 12 Dec 89 12:08:54 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA21207; Tue, 12 Dec 89 15:04:34 EST
Received: from Think.COM ([131.239.2.1]) by zurich.ai.mit.edu; Tue, 12 Dec 89 15:03:11 est
Received: from Fafnir.Think.COM by Think.COM; Tue, 12 Dec 89 15:06:13 -0500
Received: from verdi.think.com by fafnir.think.com; Tue, 12 Dec 89 15:01:17 EST
Received: from ungar.think.com by verdi.think.com; Tue, 12 Dec 89 14:59:09 EST
From: gls@think.com (Guy Steele)
Received: by ungar.think.com; Tue, 12 Dec 89 14:59:07 EST
Date: Tue, 12 Dec 89 14:59:07 EST
Message-Id: <8912121959.AA09811@ungar.think.com>
To: KMP@stony-brook.scrc.symbolics.com
Cc: RRRS-Authors@zurich.ai.mit.edu, KMP@stony-brook.scrc.symbolics.com
In-Reply-To: Kent M Pitman's message of Mon, 11 Dec 89 18:15 EST <19891211231534.8.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: Dynamic binding
Date: Mon, 11 Dec 89 18:15 EST
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
...
The situation is analogous to the naming of the "funny little thing at
the end of a shoelace that keeps it from fraying". I hear there's a
name for the thing, but the fact is that it's not in the standard
dialect which most people speak ...
"aglet"
∂12-Dec-89 1420 @zurich.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu re: Dynamic binding
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 12 Dec 89 14:20:24 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA22942; Tue, 12 Dec 89 17:15:56 EST
Received: from skinner.cs.uoregon.edu ([128.223.4.13]) by zurich.ai.mit.edu; Tue, 12 Dec 89 17:14:00 est
Received: from spencer.cs.uoregon.edu by skinner.cs.uoregon.edu with SMTP
(5.61.14/IDA-1.2.8) id AA11270; Tue, 12 Dec 89 12:57:52 -0800
Received: by spencer.cs.uoregon.edu; Tue, 12 Dec 89 12:56:45 PST
Date: Tue, 12 Dec 89 12:56:45 PST
From: will@cs.uoregon.edu
Message-Id: <8912122056.AA13631@spencer.cs.uoregon.edu>
To: Gyro@reasoning.com, RPG@sail.stanford.edu, RRRS-Authors@zurich.ai.mit.edu
Subject: re: Dynamic binding
RPG replies to Gyro:
Not actually: we have only made [GOTO] harder to spell and split its name
in two parts, one of which the user gets to choose. It is now called
call-with-current-continuation/<a name of your choosing here>.
[No smiley face]
Actually: Sussman and Steele generalized GOTO when most people were
trying to abolish it. This generalization was successful: It is
easier to make a case for CALL-WITH-CURRENT-CONTINUATION than for
GOTO, and it would almost be irrational to design a new language that
includes unrestricted GOTOs but doesn't include an equivalent to
CALL-WITH-CURRENT-CONTINUATION. On the other hand, it is perfectly
rational to design a new language that includes neither.
It is also perfectly rational to design a language that does not include
dynamics. It's interesting that fluid variables were originally part of
Scheme, were effectively dropped from the language during the drive for
simplicity, and are now being proposed again in rather different form.
[begin smiley face]
In any tradeoff between simplicity and power, there are two principled
positions. Maybe we should have Scheme Level 0, which includes neither
CALL-WITH-CURRENT-CONTINUATION nor dynamics, and Scheme Level 1, which
includes both CALL-WITH-CURRENT-CONTINUATION and the appropriate
generalization of dynamics.
I got to thinking about the choice between abolishing or generalizing
the historical distinction between the value and function environments
in Lisp, and for a moment I thought that we should also have Lisp Level 0,
which uses only one environment, and Lisp Level 1, which has an infinity
of environments, one for each type. Then I realized that Lisp Level 0 is
both simpler and more powerful than Lisp Level 1, so this wouldn't make
sense.
[end smiley face]
Peace, Will
∂12-Dec-89 1539 @zurich.ai.mit.edu,@VIOLA.Reasoning.COM:Gyro@UUCP re: Dynamic binding
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 12 Dec 89 15:39:25 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA24242; Tue, 12 Dec 89 18:37:06 EST
Received: from drums.reasoning.com ([192.5.238.120]) by zurich.ai.mit.edu; Tue, 12 Dec 89 18:35:21 est
Received: from [192.5.238.128] by drums.reasoning.com with SMTP (5.61/25-eef)
id AA03310; Tue, 12 Dec 89 15:36:11 -0800
for RRRS-Authors@zurich.ai.mit.edu
Date: Tue, 12 Dec 89 15:37 PST
From: Gyro@reasoning.com
Subject: re: Dynamic binding
To: RRRS-Authors@zurich.ai.mit.edu
In-Reply-To: <oJ85Z@SAIL.Stanford.EDU>
Message-Id: <19891212233736.6.GYRO@VIOLA.Reasoning.COM>
Date: 12 Dec 89 0912 PST
From: Dick Gabriel <RPG@sail.stanford.edu>
[In reply to message from Gyro@reasoning.com sent Tue, 12 Dec 89 02:00 PST.]
Gyro writes:
But we Schemers have abandoned GOTO in favor of the procedure call in
tail-recursive position, and rightly so, the idea being that we slightly....
Not actually: we have only made it harder to spell and split its name
in two parts, one of which the user gets to choose. It is now called
call-with-current-continuation/<a name of your choosing here>.
I'm not talking about CALL/CC. (In fact, I'm not quite sure what you
mean; invoking a captured continuation does not seem at all like GOTO.)
I'm talking about the observation that if it is argument evaluation, not
function invocation, that saves context -- this is the fundamental way
that a Scheme implementation differs from that of other Lisps -- then
GOTO is just like invoking a function of no arguments. (This is all
discussed in the "LAMBDA: The Ultimate X" papers, of course.)
-- Scott
∂12-Dec-89 2247 @zurich.ai.mit.edu,@VIOLA.Reasoning.COM:Gyro@UUCP Modules vs. dynamic binding
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 12 Dec 89 22:47:20 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA29701; Wed, 13 Dec 89 01:41:30 EST
Received: from drums.reasoning.com ([192.5.238.120]) by zurich.ai.mit.edu; Wed, 13 Dec 89 01:39:42 est
Received: from [192.5.238.128] by drums.reasoning.com with SMTP (5.61/25-eef)
id AA03588; Tue, 12 Dec 89 22:40:26 -0800
for rrrs-authors@zurich.ai.mit.edu
Date: Tue, 12 Dec 89 22:41 PST
From: Gyro@reasoning.com
Subject: Modules vs. dynamic binding
To: rrrs-authors@zurich.ai.mit.edu
Cc: Gyro@reasoning.com
In-Reply-To: <8912121138.AA10395@zurich.ai.mit.edu>
Message-Id: <19891213064145.7.GYRO@VIOLA.Reasoning.COM>
Date: Tue, 12 Dec 89 06:38:57 est
From: cph@zurich.ai.mit.edu (Chris Hanson)
Scott, this technique you propose is a useful one, but I don't believe
it provides a replacement for dynamic binding. The problem with the
technique is that the procedure `read' cannot be embedded in another
program unless the embedding program is also parameterized in a
similar way (by "embedded" I mean that the variable `read' is bound in
some closing environment of the embedding program).
To properly take advantage of this technique (as you point out), every
embedding program must be parameterized, and furthermore the
parameters of the embedded program must also be parameters of the
embedding program.
I don't think the latter is true at all. Many programs will use READ,
for instance, but will not want to inherit the various parameters of the
reader from programs in which they are embedded. In fact, the original
motivating example I gave was of just such a case.
Clearly nobody wants
to write all of that specialization by hand, and yes, all this "late
binding" can be hidden by a module system; but what about the program
that occasionally specializes itself as it runs? Does the module
system know how to create new programs on the fly, or is it restricted
to describing more static relationships?
Remember that "creating a new program" amounts to evaluating (i.e.,
closing) a set of lambda-expressions. It's a familiar, primitive, and
efficient operation (at least, it had better be).
Ultimately this "module system" becomes an integral part of the
language -- it has introduced a new kind of binding with "dynamic"
characteristics.
No, that's exactly what it hasn't done. It is using the same old kind
of binding that we all know and love to accomplish the same ultimate
purpose as dynamically bound parameters, but in a different way.
What are the semantics of this binding? Is it
different from what we now think of as "dynamic binding"? Is this
really a new idea or just a new implementation of an old idea?
I will vigorously defend myself against any intimation that I am saying
anything new. :-) But no, it is neither of those things. It is, at
best, a new application of an existing implementation of an old idea.
Another solution to this problem was invented by John Lamping a few
years ago: he introduced another kind of variable that could be bound
after the program was constructed. These variables can be considered
to be "holes" in the program, which can be filled in at any time by a
virtual-copy process that produced a new program in which a particular
set of "holes" was filled. Program fragments can be combined into
larger program fragments, independent of whether they have "holes";
"matching holes" in two program fragments become identified in the
combined fragment. With this solution, `read' would have such a
variable for its radix, and this variable would be unspecified when
`read' was defined. You could then embed `read' in some big program,
and just before you were ready to run it, you could specialize the
embedding program with the desired radix.
This sounds complicated and inelegant by comparison with what I propose.
Lamping's solution has some major advantages over what you propose:
* The embedding program doesn't have to know anything about what
"holes" `read' has.
I consider that a disadvantage -- a serious one. Indeed, it is
precisely one of those properties of the dynamic-binding approach that I
am complaining about.
* The values being supplied to the "holes" can be collected
together in an environment and supplied all at once. A "default
environment" can easily be created, and the user can override
particular bindings in that environment by shadowing.
This is a good idea, and I would certainly want to incorporate it.
* It is clearly a change to the language itself rather than a
system that at least nominally is not a fundamental part of the
language.
Again, I consider this a disadvantage.
But are either of these solutions really so different from dynamic
binding? You claim that dynamic binding is destructive to modularity,
but with the implementation proposed by Pavel the designer must
clearly state the intention that a particular parameter may be
dynamically bound, so the parameter is clearly part of the program's
abstraction boundary (if you can get your hands on it).
I don't see that. I don't see what's to stop me from defining a bunch
of variables at top-level to be bound to Dynamics (or whatever they wind
up being called) and then just using them like special variables.
Granted, such parameters are logically part of the program's
abstraction; my observation is that in practice, they don't wind up
being specified as such. That's part of my complaint.
I think this topic is an interesting one that falls between the
cracks: it's a little too dynamic for modules, and not dynamic enough
for procedural arguments. I'd like to see some work done on
understanding this; I suspect that Lamping's work is a good first step
(implementing his language efficiently is quite challenging).
(Implementing my proposal efficiently is quite straightforward.)
On the other hand, I have a strong feeling that dynamic binding is the
best solution to this problem for Scheme -- a better solution may
require changes that are fundamental enough that the result may no
longer be "Scheme-like".
That may well be true; although the funny thing is, the longer I think
and talk about this, the more convinced I am that my proposal is
entirely appropriate for Scheme. I don't always convince myself so
effectively!
-- Scott
∂12-Dec-89 2324 @zurich.ai.mit.edu,@mc.lcs.mit.edu,@zermatt.lcs.mit.edu,@viola.reasoning.com:Gyro@eddie.mit.edu RE: dynamic bindng
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 12 Dec 89 23:23:57 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA00145; Wed, 13 Dec 89 02:20:44 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Wed, 13 Dec 89 02:18:58 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa24841;
13 Dec 89 2:08 EST
Received: from ZERMATT.LCS.MIT.EDU (CHAOS 17316) by MC.LCS.MIT.EDU; 13 Dec 89 02:09:15 EST
Received: from drums.reasoning.com (REASONING.COM) by ZERMATT.LCS.MIT.EDU via INTERNET with SMTP id 317760; 13 Dec 89 02:07:32 EST
Received: from [192.5.238.128] by drums.reasoning.com with SMTP (5.61/25-eef)
id AA03606; Tue, 12 Dec 89 23:06:45 -0800
for rrrs-authors@zermatt.lcs.mit.edu
Date: Tue, 12 Dec 89 23:08 PST
From: Gyro@reasoning.com
Subject: RE: dynamic bindng
To: rrrs-authors@zermatt.lcs.mit.edu
In-Reply-To: <8912121810.AA01118@hx.LCS.MIT.EDU>
Message-Id: <19891213070812.8.GYRO@VIOLA.Reasoning.COM>
Date: Tue, 12 Dec 89 13:10:43 EST
From: "Michael R. Blair" <ziggy@hx.lcs.mit.edu>
I use FLUID-LET to dynamically rebind environmnent variables, like
*debugging?* *alpha-rename* *found-an-error?*... things that look like
they could be arguments but which would have to be included in every
procedure of a complex module so the info could propagate and percolate
to those few procedures which actually use them.
If you view a module as an object in the Object-Oriented sense, these
effectively correspond to modifiable instance variables.
It sounds like you may have the basic idea. Consider: if you are
debugging the methods of a class, you can have instance variables such
as you mention; you can have one instance of the class in which these
instance variables are bound to "experimental" values, and other
instances in which they are bound to "sane default" values. You can
debug using the former, while your system performs its normal operations
using the latter.
Again, I use FLUID-LET (which I hope uses dynamic-unwind) to reset
my state to a sane default if/when I blow out into the debugger
and abort.
By the way, what I was alluding to whith my reference to exception
handling was that something like (SIGNAL over-flow "Overflow on
arg to SQUARE" arg) will invoke something which depends non who the
dynamic caller to SQUARE was. It involves dynamically binding a
handler that the callee invokes upon error (default is "the no handler
handler"). This is the classic way that exception handling is presented
in a denotational sematics setting (namely, bind a handler continuation
in a dynamic environment.
Exception handler binding is, certainly, the weak point in my proposal.
I *think* it would make sense to use the lexical approach for exception
handlers as well, but I confess I haven't given this as much thought as
for other uses of dynamic binding, and I have a much harder time
defending my proposal against someone who claims that these simply are
dynamic by nature.
Hmm... let me mull this one over further.
-- Scott
∂14-Dec-89 0833 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #258
Received: from life.ai.mit.edu ([128.52.32.80]) by SAIL.Stanford.EDU with TCP; 14 Dec 89 08:33:30 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA13893; Thu, 14 Dec 89 09:48:41 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Thu, 14 Dec 89 09:46:37 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa27087;
14 Dec 89 9:04 EST
Date: 14 DEC 89 08:05:45 EST
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.lcs.mit.edu>
Subject: Scheme Digest #258
To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Message-Id: <8912140905.aa27087@mintaka.lcs.mit.edu>
Scheme Digest #258 14 DEC 89 08:05:45 EST
Today's Topics:
continuation based error handling
----------------------------------------------------------------------
Date: 14 Dec 89 01:14:40 GMT
From: Paul Snively <wuarchive!brutus.cs.uiuc.edu!apple!apple.com!chewy@eddie.mit.edu>
Subject: Re: continuation based error handling
Message-Id: <5754@internal.Apple.COM>
In article <4169@amelia.nas.nasa.gov> raible@orville.nas.nasa.gov (Eric
Raible) writes:
> It seems to me that it ought to be possible to implement a somewhat
> portable error handling facility using call/cc.
>
> I'd appreciate comments and/or code.
Well, Common Lisp's CATCH and THROW are certainly trivial when you have
full upward continuations; I think Dybvig's book gives examples.
__________________________________________________________________________
Just because I work for Apple Computer, Inc. doesn't mean that they
believe what I believe or vice-versa.
__________________________________________________________________________
C++ -- The language in which only friends can access your private members.
__________________________________________________________________________
------------------------------
End of Scheme Digest
********************
∂14-Dec-89 2150 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #259
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 14 Dec 89 21:50:41 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA28395; Fri, 15 Dec 89 00:49:07 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Fri, 15 Dec 89 00:47:17 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa24351;
15 Dec 89 0:29 EST
Date: 15 DEC 89 00:04:15 EST
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.lcs.mit.edu>
Subject: Scheme Digest #259
To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Message-Id: <8912150029.aa24351@mintaka.lcs.mit.edu>
Scheme Digest #259 15 DEC 89 00:04:15 EST
Today's Topics:
Scheme book by Springer and Friedman
Scheme book by Springer and Friedman
Anyone have CScheme7, T3.1, Elk 1.0 on Apollo SR10.2
----------------------------------------------------------------------
Message-Id: <QZVyBD600VsAInCkIW@andrew.cmu.edu>
Date: Thu, 14 Dec 89 13:15:43 -0500 (EST)
From: Mark Sherman <mss+@andrew.cmu.edu>
Subject: Scheme book by Springer and Friedman
Is anyone familar with the book "Scheme and the Art of Programming" by
Springer & Friedman (MIT Press)? I'm looking for something for bright
high school students. (Please respond to me, I don't normally read this
newgroup, thanks.)
-Mark
------------------------------
Date: 14 Dec 89 20:13:49 GMT
From: Richard Pattis <pattis@june.cs.washington.edu>
Subject: Re: Scheme book by Springer and Friedman
Message-Id: <10189@june.cs.washington.edu>
In article <QZVyBD600VsAInCkIW@andrew.cmu.edu>, mss+@ANDREW.CMU.EDU (Mark Sherman) writes:
> Is anyone familar with the book "Scheme and the Art of Programming" by
> Springer & Friedman (MIT Press)? I'm looking for something for bright
> high school students. (Please respond to me, I don't normally read this
> newgroup, thanks.)
> -Mark
When asking such a question, is it appropriate for the inquirer to also say
that he/she will post responses to the net? As a faithful comp.lang.scheme
reader, who is interested in the topic, and took the time to read the
message, I would like to profit from any responses generated by this
newsgroup.
Rich Pattis
------------------------------
Date: 13 Dec 89 14:44:11 GMT
From: The Bhagwan <fluke!ssc-vax!voodoo!bhagwan@beaver.cs.washington.edu>
Subject: Anyone have CScheme7, T3.1, Elk 1.0 on Apollo SR10.2
Message-Id: <631@voodoo.UUCP>
Hello,
I'm looking for anyone that has:
MIT C-Scheme-7
Yale T3.1
or Elk 1.0
compiled and running on Apollo SR10.2 (68xxx).
I can ftp source but we have no assembler so cannot build.
If anyone has done this perhaps you can let me know and we'll
make arrangements to mail binaries. Also, I can ftp.
Thanks,
--
Al McPherson Member Holstein Aerobatic Team
Boeing Computer Services ...uw-beaver!ssc-vax!voodoo!bhagwan
P.O. Box 24346 MS: 6M-49 Seattle, WA 98124 (206) 234-7825
------------------------------
End of Scheme Digest
********************
∂15-Dec-89 2227 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #260
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 15 Dec 89 22:27:12 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA18162; Sat, 16 Dec 89 01:23:54 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Sat, 16 Dec 89 01:21:27 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa02111;
16 Dec 89 0:57 EST
Date: 16 DEC 89 00:04:18 EST
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.lcs.mit.edu>
Subject: Scheme Digest #260
To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Message-Id: <8912160057.aa02111@mintaka.lcs.mit.edu>
Scheme Digest #260 16 DEC 89 00:04:18 EST
Today's Topics:
Scheme book by Springer and Friedman
Scheme book by Eisenberg
Scheme book by Springer and Friedman
Errors in the SCOOPS for the Macintosh
Scheme book by Springer and Friedman
Scheme book by Eisenberg
----------------------------------------------------------------------
Date: Fri, 15 Dec 89 02:16 EST
From: Andre van Meulebrouck <vanMeule@allegheny.scrc.symbolics.com>
Subject: Scheme book by Springer and Friedman
Message-ID: <19891215071609.2.VANMEULE@PERTA.SCRC.Symbolics.COM>
Date: Thu, 14 Dec 89 13:15:43 -0500 (EST)
From: Mark Sherman <mss+@andrew.cmu.edu>
Is anyone familar with the book "Scheme and the Art of Programming" by
Springer & Friedman (MIT Press)? I'm looking for something for bright
high school students. (Please respond to me, I don't normally read this
newgroup, thanks.)
-Mark
I just skimmed it, looking over every page briefly, so take my comments with
that in mind.
I bought it because it has a nice section on continuations (which I felt I could
profit from to become more comfortable with them), and for reference purposes
because it does go into some pretty deep and interesting examples that show not
just Scheme, but various programming paradigms and how to use them (in a similar
manner to "Structure and Interpretation of Computer Programs"'s approach).
The latter is especially nice as Scheme, elegant as it is, is ultimately "just"
a vehicle by which to express algorithms and concepts, so some discussion of
what to "say" once you learn "speak" Scheme is important (as well as the
comments here and there as to why it might perhaps be easier to say them in
Scheme than in other languages).
The book seems to me to be very concise, complete, readable, and text-bookish
(in that I believe it has lots of exercises, almost like a math book) so I
should think it would suit your purposes well.
My *real* intent in replying to this message however was to change the subject
<grin>, as it reminded me about a book I'm curious about.
Specifically, has anyone looked at a copy of the (relatively) recent
"Introduction to Functional Programming" by Bird and Wadler of Oxford and
Glasgow Universities (Prentice Hall, March 1988)?
------------------------------
Date: Fri, 15 Dec 89 08:54:31 est
From: Franklyn Turbak <lyn@zurich.ai.mit.edu>
Message-Id: <8912151354.AA02180@zurich.ai.mit.edu>
Subject: Scheme book by Eisenberg
In article <QZVyBD600VsAInCkIW@andrew.cmu.edu>, mss+@ANDREW.CMU.EDU (Mark Sherman) writes:
> Is anyone familar with the book "Scheme and the Art of Programming" by
> Springer & Friedman (MIT Press)? I'm looking for something for bright
> high school students.
I highly recommend Mike Eisenberg's "Programming in Scheme" (Scientific
Press). It was specifically written with high school students in mind,
but is an excellect general introduction to Scheme for just about
anyone. It's well organized, beautifully written, and chock full of
fun and interesting examples (including an Eliza-like program
based on Abbot and Costello's "Who's on first" routine).
------------------------------
Date: Fri, 15 Dec 89 13:39:52 est
From: Julie Sussman <jems@zurich.ai.mit.edu>
Message-Id: <8912151839.AA01268@zurich.ai.mit.edu>
Subject: Scheme book by Springer and Friedman
I haven't seen that book yet, but there is a wonderful Scheme book
intended especially for bright high-school students. It is
"Programming in Scheme" by Michael Eisenberg. Published by the
Scientific Press, but MIT Press is (or shortly will be) distributing
it too. It is geared for use with TI's PC Scheme (i.e. the machine-
dependent examples, such as graphics, are for that Scheme), and
a MacIntosh version will be out soon. But it is not critical that
the book and your Scheme version match.
Julie Sussman (jems@zurich.ai.mit.edu)
------------------------------
Date: 15 Dec 89 17:52:50 GMT
From: Kai Zimmermann <mcsun!unido!fauern!tumuc!lan!zimmerma@uunet.uu.net>
Subject: Errors in the SCOOPS for the Macintosh
Message-Id: <970@tuminfo1.lan.informatik.tu-muenchen.dbp.de>
Hello everybody,
I have discovered and REMOVED two errors in the implementation
of TI's SCOOPS package for the Apple Macintosh that comes
with Lightship's MacScheme.
1. You can't work with the special instance variable SELF
because it's not bound to the instance itself but to the
dispatching procedure for that instance.
2. (describe <any instance>) produces an error if you haven't
defined any class that uses CLASSVARS yet.
Thus,
(load "SCOOPS")
(define-class foo)
(define fie (make-instance foo))
(describe fie)
results in an error,
but
(load "SCOOPS")
(define-class foo)
(define-class dummy (CLASSVARS WeNeedJustOne))
(define fie (make-instance foo))
(describe fie)
works.
The following code will remove these errors and documents why they
occured. If anyone has discovered more errors I'd like to hear of them.
Hope I helped someone with this posting,
--Kai
=========================================================================
| I started lisp programming with the Xerox Interlisp-D environment, |
| moved down (at that time) to the Symbolics programming environment, |
| had to work with the Allegro Commonlisp environment? |
| and now finally work in MacScheme. |
| Tomorrow I will work in lisp bytecode directly |
| with nothing but a hardcopy teletype as input device. |
| Would be nearly no difference :-( |
| |
| Kai Zimmermann zimmerma@lan.informatik.tu-muenchen.dbp.de |
=========================================================================
----------Cut Here-------------
; Just replace the definitions of the procedures
; INSTANCE-DESCRIPTION and
; COMPILE-MAKE-FN
; in the source file that comes with MacScheme
; by the following code.
(define instance-description
(let ((*key* *key*)
(inheritance inheritance)
(writeln (lambda l (for-each display l) (newline))))
(lambda (inst)
(letrec ((class (send inst get-class))
(printvars
(lambda (f1 f2) ;f1 is a list of instvars and f2 an environment
(let ((n 0))
(while f1
(writeln " " (car f1) " : " (vector-ref f2 n))
(set! n (1+ n))
(set! f1 (cdr f1)))))))
(writeln " ")
(writeln " INSTANCE DESCRIPTION")
(writeln " ====================")
(writeln " ")
(writeln " Instance of Class " (send (class *key*) name))
(writeln " ")
(writeln " Class Variables : ")
(printvars (mapcar car (inheritance class 'get-classvars ))
; Kai Zimmermann, 1989
; Here was an error due to the fact that in
; PC-Scheme (car '()) returns () and in
; MacScheme an error is signalled.
(let ((possibly-empty-environment
(send (class *key*) get-class-environment)))
(if (null? possibly-empty-environment)
'()
(car possibly-empty-environment))))
(writeln " ")
(writeln " Instance Variables :")
(printvars (mapcar car (inheritance class 'get-instvars))
(cadr (->pair (car (->pair inst)))))
(string->symbol "")
))))
;-----------
(define compile-make-fn
(lambda (x)
(let* ((params (gensym "init-parms"))
(instvars (instance-vars x))
(totalvars (append instvars (class-vars x))))
`(lambda
,params
(letrec
,(append
(format-vars instvars)
(list
(list 'self
`(lambda
msg
(case (car msg)
,@(format-case
(append
`((get-class (lambda (),x)))
(get-methods (inheritance x 'get-gettable)
totalvars)
(set-methods (inheritance x 'get-settable)
totalvars)
(inheritance x 'get-methods)
)))))))
; Kai Zimmermann, 1989
; Here was an error, because self wasn't changed
; to the constructed symbol, but left as
; the above lambda. This made it impossible to
; work with self.
(set! self
(->symbol
(list self
',(cons 'pname
(string-append "#<INSTANCE "
(symbol->string
(send (x *key*) name))
">")))))
,(compile-init-code x params)
self)))))
;------------End----------
------------------------------
Date: 15 Dec 89 17:23:59 GMT
From: Paul Snively <zaphod.mps.ohio-state.edu!usc!apple!apple.com!chewy@ohio-state.arpa>
Subject: Re: Scheme book by Springer and Friedman
Message-Id: <5800@internal.Apple.COM>
In article <19891215071609.2.VANMEULE@PERTA.SCRC.Symbolics.COM>
vanMeule@ALLEGHENY.SCRC.SYMBOLICS.COM (Andre van Meulebrouck) writes:
[Lots o' stuff about Scheme and the Art of Programming removed]
First, a message for Andre':
Hey! So THAT'S where you disappeared to! :-)
Now, back to the subject at hand:
Dan Friedman was kind enough to send me a copy of his (co-authored) new
book, and I am very pleased with it. I think it would be perfectly fine
for bright high-school students, especially if the students are NOT
carrying around a lot of preconceived baggage from BASIC/Pascal/C when
they get into this. They'll have less to unlearn that way.
I'm with Andre'; I particularly appreciated the in-depth discussion of
continuations (two chapters that Dan Friedman called "a labor of love,"
and it shows). Like many texts, the books is a tad short on example
applications of the methodologies, but that is really my only criticism,
and it's intended to be a mild one (Structure and Interpretation of
Computer Programs has lots of examples of application; I think between
these two texts, you've got an EXTREMELY good computer science course with
an emphasis on Scheme).
__________________________________________________________________________
Just because I work for Apple Computer, Inc. doesn't mean that they
believe what I believe or vice-versa.
__________________________________________________________________________
C++ -- The language in which only friends can access your private members.
__________________________________________________________________________
------------------------------
Date: 15 Dec 89 20:41:51 GMT
From: Vincent Manis <ubc-cs!manis@beaver.cs.washington.edu>
Subject: Re: Scheme book by Eisenberg
Message-Id: <5992@ubc-cs.UUCP>
We've been using Eisenberg's text on Scheme as a supplementary in our
`SICP section' of our first year course. The students quite like it (and
I like it too!). The current edition is keyed to PC-Scheme, but as I
understand it, a MacScheme version is in production.
--
\ Vincent Manis <manis@cs.ubc.ca> "There is no law that vulgarity and
\ Department of Computer Science literary excellence cannot coexist."
/\ University of British Columbia -- A. Trevor Hodge
/ \ Vancouver, BC, Canada V6T 1W5 (604) 228-2394
------------------------------
End of Scheme Digest
********************
∂16-Dec-89 1048 @zurich.ai.mit.edu,@VIOLA.Reasoning.COM:Gyro@UUCP re: Dynamic binding
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 16 Dec 89 10:47:57 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA22416; Sat, 16 Dec 89 13:45:43 EST
Received: from drums.reasoning.com ([192.5.238.120]) by zurich.ai.mit.edu; Sat, 16 Dec 89 13:43:56 est
Received: from [192.5.238.128] by drums.reasoning.com with SMTP (5.61/25-eef)
id AA10112; Sat, 16 Dec 89 10:42:48 -0800
for RRRS-Authors@zurich.ai.mit.edu
Date: Sat, 16 Dec 89 10:43 PST
From: Gyro@reasoning.com
Subject: re: Dynamic binding
To: RRRS-Authors@zurich.ai.mit.edu
In-Reply-To: <8912122056.AA13631@spencer.cs.uoregon.edu>
Message-Id: <19891216184359.2.GYRO@VIOLA.Reasoning.COM>
As fate would have it, I am at this moment attempting to debug a piece
of Common Lisp code which, for some non-obvious reason, only works right
if *PACKAGE* is set to a particular package. No doubt some function
somewhere in it is doing something that involves *PACKAGE* -- interning
would be my first guess, though as it happens I have no idea why it
should be interning anything -- but I have no idea what part of the code
might be doing this or, as I say, why.
This is the kind of thing I'm complaining about.
-- Scott
∂16-Dec-89 1226 RPG@sail.stanford.edu re: Dynamic binding
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 16 Dec 89 12:26:09 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA23173; Sat, 16 Dec 89 15:23:59 EST
Received: from SAIL.Stanford.EDU (sail.stanford.edu) by zurich.ai.mit.edu; Sat, 16 Dec 89 15:21:39 est
Message-Id: <WLpgb@SAIL.Stanford.EDU>
Date: 16 Dec 89 1222 PST
From: Dick Gabriel <RPG@sail.stanford.edu>
Subject: re: Dynamic binding
To: Gyro@reasoning.com, RRRS-Authors@zurich.ai.mit.edu
[In reply to message from Gyro@reasoning.com sent Sat, 16 Dec 89 10:43 PST.]
The Common Lisp package system is pretty obscure and admits very strange bugs
in code if the package structure is not carefully controlled at every stage of
loading/development. Is there a proposal to put packages in Scheme and that
is what you are complaining about? Or is it the use of defaults for setting the
current package?
-rpg-
∂16-Dec-89 1731 @zurich.ai.mit.edu,@VIOLA.Reasoning.COM:Gyro@UUCP re: Dynamic binding
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 16 Dec 89 17:31:00 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA25482; Sat, 16 Dec 89 20:29:23 EST
Received: from drums.reasoning.com ([192.5.238.120]) by zurich.ai.mit.edu; Sat, 16 Dec 89 20:27:29 est
Received: from [192.5.238.128] by drums.reasoning.com with SMTP (5.61/25-eef)
id AA10231; Sat, 16 Dec 89 17:28:09 -0800
for RRRS-Authors@ZURICH.AI.MIT.EDU
Date: Sat, 16 Dec 89 17:29 PST
From: Gyro@reasoning.com
Subject: re: Dynamic binding
To: RRRS-Authors@zurich.ai.mit.edu
In-Reply-To: <WLpgb@SAIL.Stanford.EDU>
Message-Id: <19891217012930.5.GYRO@VIOLA.Reasoning.COM>
Date: 16 Dec 89 1222 PST
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
[In reply to message from Gyro@reasoning.com sent Sat, 16 Dec 89 10:43 PST.]
The Common Lisp package system is pretty obscure and admits very strange bugs
in code if the package structure is not carefully controlled at every stage of
loading/development. Is there a proposal to put packages in Scheme and that
is what you are complaining about? Or is it the use of defaults for setting the
current package?
The latter (*PACKAGE* just makes a good example for discussion, because
it's something that (I assume) everyone knows about). More precisely, I
object to the fact that, for instance, I can readily be calling some
routine A which calls some routine which ... references the special
variable *B*, so that the value of *B* is properly part of A's interface
specification, without any clear indication in the source code that that
is the case. (It's logically possible, of course, that a Lisp
programmer would list, as part of each procedure's documentation, all
special variables the procedure or any of its transitive callees
reference, and would maintain those lists as the code was edited, but
I've never seen it done; it would be just as much work as passing all
such values via required arguments, which is exactly what the use of
specials is supposed to obviate.)
-- Scott
∂16-Dec-89 2217 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #261
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 16 Dec 89 22:17:32 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA27823; Sun, 17 Dec 89 01:15:08 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Sun, 17 Dec 89 01:13:12 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa07766;
17 Dec 89 0:53 EST
Date: 17 DEC 89 00:04:18 EST
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.lcs.mit.edu>
Subject: Scheme Digest #261
To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Message-Id: <8912170053.aa07766@mintaka.lcs.mit.edu>
Scheme Digest #261 17 DEC 89 00:04:18 EST
Today's Topics:
a self-contained lisp environment, siod and micro emacs.
----------------------------------------------------------------------
Message-Id: <8912160734.AA11135@schizo.samsung.com>
Reply-To: gjc@mitech.com
Date: Fri, 15 Dec 89 16:52:56 EDT
From: gjc@mitech.com
Subject: a self-contained lisp environment, siod and micro emacs.
An "emacs" subr may be defined for siod-v2.3-shar (Scheme In One Day) with
trivial modifications to micro-emacs. The resulting behavior is that
when you exit emacs and re-enter, your buffers are in the same state as before.
How to call micro emacs from siod. (Done with MicroEMACS 3.7)
Modify DISPLAY.C
- Make sure vscreen is initialized to NULL at top of file.
VIDEO **vscreen = NULL;
- Then add a line to vtinit before the malloc of vscreen.
if (vscreen != NULL) return(1);
Modify MAIN.C
- rename the function main to main_hacked.
- conditionalize the call to edinit to be
if (argc > -1) edinit(bname);
- before this line: viewflag = FALSE; add this line:
sgarbf = TRUE;
- conditionalize the call to startup to be
if (argc > -1) startup("");
- in the function quit replace exit with exit_hacked.
Modify SLIB.C
There are name conflicts on functions "eq" and "quit"
so I just renamed these to "l_eq" and "l_quit" in slib.c
Easier than modifying micro-emacs.
Add this new subr to siod.c:
#include <setjmp.h>
long uemacs_need_init = 1;
jmp_buf uemacs_exit;
exit_hacked(value)
int value;
{longjmp(uemacs_exit,2);}
LISP uemacs_call()
{long flag,k;
flag = no_interrupt(1);
k = setjmp(uemacs_exit);
if (k == 2)
{uemacs_need_init = 0;
no_interrupt(flag);
return(NIL);}
if (uemacs_need_init)
{main_hacked(0,0);
uemacs_need_init = 0;}
else
main_hacked(-1,0);
no_interrupt(flag);
return(NIL);}
init_subr("emacs",tc_subr_0,uemacs_call);
Here are the diffs.
************
File UTIL$DISK:[UEMACS]MAIN_HACKED.C;5
353 main_hacked(argc, argv)
354 char *argv[];
******
File UTIL$DISK:[UEMACS]MAIN_HACKED.C;1
353 main(argc, argv)
354 char *argv[];
************
************
File UTIL$DISK:[UEMACS]MAIN_HACKED.C;5
380 if (argc > -1)
381 edinit(bname); /* Buffers, windows. */
382 sgarbf = TRUE; /* new */
383 viewflag = FALSE; /* view mode defaults off in command line */
******
File UTIL$DISK:[UEMACS]MAIN_HACKED.C;1
380 edinit(bname); /* Buffers, windows. */
381 viewflag = FALSE; /* view mode defaults off in command line */
************
************
File UTIL$DISK:[UEMACS]MAIN_HACKED.C;5
465 if (argc > -1) startup("");
466 startf = TRUE;
******
File UTIL$DISK:[UEMACS]MAIN_HACKED.C;1
463 startup("");
464 startf = TRUE;
************
************
File UTIL$DISK:[UEMACS]MAIN_HACKED.C;5
753 exit_hacked(GOOD);
754 }
******
File UTIL$DISK:[UEMACS]MAIN_HACKED.C;1
751 exit(GOOD);
752 }
************
************
File UTIL$DISK:[UEMACS]DISPLAY.C;2
32 VIDEO **vscreen = NULL; /* Virtual screen. */
33 #if IBMPC == 0
******
File UTIL$DISK:[UEMACS]DISPLAY.C;1
32 VIDEO **vscreen; /* Virtual screen. */
33 #if IBMPC == 0
************
************
File UTIL$DISK:[UEMACS]DISPLAY.C;2
52
53 if (vscreen != NULL) return(1);
54
55 vscreen = (VIDEO **) malloc(term.t_nrow*sizeof(VIDEO *));
******
File UTIL$DISK:[UEMACS]DISPLAY.C;1
52 vscreen = (VIDEO **) malloc(term.t_nrow*sizeof(VIDEO *));
************
------------------------------
End of Scheme Digest
********************
∂17-Dec-89 2121 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #262
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 17 Dec 89 21:21:40 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA06743; Mon, 18 Dec 89 00:17:45 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Mon, 18 Dec 89 00:15:34 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa00902;
18 Dec 89 0:13 EST
Date: 18 DEC 89 00:04:19 EST
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.lcs.mit.edu>
Subject: Scheme Digest #262
To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Message-Id: <8912180013.aa00902@mintaka.lcs.mit.edu>
Scheme Digest #262 18 DEC 89 00:04:19 EST
Today's Topics:
Articles on compiling scheme
----------------------------------------------------------------------
Date: 17 Dec 89 16:08:32 GMT
From: Jason Coughlin <snorkelwacker!usc!brutus.cs.uiuc.edu!rpi!image.soe.clarkson.edu!jk0@bloom-beacon.mit.edu>
Subject: Articles on compiling scheme
Message-Id: <1989Dec17.160832.7157@sun.soe.clarkson.edu>
I wrote a Scheme interpreter which I am going to turn into a byte-code
compiler. Can anyone please send me references to articles about
compiling scheme and/or compiling LISP?
Please email as I don't read this group that much. Thanks for your
help.
--
Jason Coughlin ( jk0@sun.soe.clarkson.edu , jk0@clutx )
"Every jumbled pile of person has a thinking part that wonders what the
part that isn't thinking isn't thinking of." - They Might Be Giants
------------------------------
End of Scheme Digest
********************
∂18-Dec-89 2145 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #263
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 18 Dec 89 21:45:12 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA22979; Tue, 19 Dec 89 00:35:30 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Tue, 19 Dec 89 00:33:43 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa29509;
19 Dec 89 0:25 EST
Date: 19 DEC 89 00:04:21 EST
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.lcs.mit.edu>
Subject: Scheme Digest #263
To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Message-Id: <8912190025.aa29509@mintaka.lcs.mit.edu>
Scheme Digest #263 19 DEC 89 00:04:21 EST
Today's Topics:
Prolog interpreter in LISP wanted
----------------------------------------------------------------------
Date: 18 Dec 89 21:16:27 GMT
From: Dorai Sitaram <titan!dorai@rice.edu>
Subject: Re: Prolog interpreter in LISP wanted
Message-Id: <3833@brazos.Rice.edu>
In article <1690@gannet.cl.cam.ac.uk> wfc@cl.cam.ac.uk (William Clocksin) writes:
$Could somebody send me the source code of a Prolog interpreter
$written in LISP (or the reference of a paper where one may be found)?
$I need this for teaching purposes only, and can't spare the time
$just at the moment to write one myself. I already know about
$the "smallest one in the world" in John Campbell's book, but I
$wonder whether somebody has got a more realistic one to share.
$Thank you.
[This is also addressed to people other than Clocksin.]
I have a fairly complete (i.e., it includes bagof and ilk, though I
didn't feel the need to add assert/detract!) and "easily" extensible
Prolog embedding written in Scheme, modeled on the one described in
Matthias Felleisen's "Transliterating Prolog into Scheme," Tech. Rep.
182, Indiana Univ. Comp. Sci. Dept., 1985. I may have referred to
this in my only previous posting on c.l.p. a few weeks ago.
It's "better" than an interpreter since it's an embedding, i.e., I can
use both languages with something approaching gay abandon. I am not
sure if this is what you want, since the language used is Scheme
(Ch*z) rather than Lisp. First-class continuations of Scheme,
something not available in Lisp, are exploited. If you think you still
want it, send me email, I'll see if I can make it subscribe to RRRS
standards to make it portable (allow time for delivery!), and email
you a copy. If you don't have a Scheme at your place, my code will
probably not be a good idea, since a Prolog embedding in a Scheme
interpreter written on top of your Lisp would be enough to break your
back, efficiency-wise, I should think.
--dorai
--
-------------------------------------------------------------------------------
It may be that the gulfs will wash us down;
It may be we shall touch the Happy Isles.
-------------------------------------------------------------------------------
------------------------------
End of Scheme Digest
********************
∂19-Dec-89 2157 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #264
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 19 Dec 89 21:57:07 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA09271; Wed, 20 Dec 89 00:55:13 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Wed, 20 Dec 89 00:53:27 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa23889;
20 Dec 89 0:35 EST
Date: 20 DEC 89 00:03:31 EST
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.lcs.mit.edu>
Subject: Scheme Digest #264
To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Message-Id: <8912200035.aa23889@mintaka.lcs.mit.edu>
Scheme Digest #264 20 DEC 89 00:03:31 EST
Today's Topics:
Scheme Digest #263
Prolog interpreter in LISP wanted
----------------------------------------------------------------------
From: afleishr@athena.mit.edu
Message-Id: <8912191604.AA05635@AALTO.MIT.EDU>
Subject: Re: Scheme Digest #263
Date: Tue, 19 Dec 89 11:04:47 EST
sir:
about your prolog in scheme,,
i should be very grateful to you for a copy.
aaron fleisher
afleisher@athena.mit.edu
------------------------------
Date: 19 Dec 89 18:10:29 GMT
From: Dorai Sitaram <titan!dorai@rice.edu>
Subject: Re: Prolog interpreter in LISP wanted
Message-Id: <3841@brazos.Rice.edu>
In article <3833@brazos.Rice.edu> dorai@titan.rice.edu (Dorai Sitaram) writes:
>[This is also addressed to people other than Clocksin.]
>
>I have a fairly complete (i.e., it includes bagof and ilk, though I
>didn't feel the need to add assert/detract!) and "easily" extensible
>Prolog embedding written in Scheme, modeled on the one described in
>[...]
>want it, send me email, I'll see if I can make it subscribe to RRRS
>standards to make it portable (allow time for delivery!), and email
>you a copy. If you don't have a Scheme at your place, my code will
>[...]
I somewhat underestimated the response I would get for the above
message. I've emailed the code to some of you, but there's still a
backlog, and there are some of you I couldn't reach. There were
suggestions that I _post_ the code. I guess, though, it'd be more
convenient to all concerned if I made it ftp'able from Rice, rather
than clog the net.
Procedure: ftp titan.rice.edu (as anonymous)
get public/slog.sh
slog.sh is a shar file, and contains two implementation files (slog.ss
and bagof.ss), two doc (loosely speaking!) files (Readme and Usage),
and a bunch of example files (mostly from Sterling&Shapiro) to make it
easy to acquire a feel for the possibly unusual syntax. The code is
_not_ completely RRRS-compatible, but should be easily fixable for the
Scheme of your choice/fate by adding requisite definitions of
extend-syntax, boxes and printf (see The Scheme Programming Language
by R. Kent Dybvig). If you encounter bugs/problems or get royally
chewed by you-don't-know-what, email me, and I'll see if I can fix it.
BTW, I would still like to get email from those who will be ftp'ing
the stuff, so that I can get back to you if there are changes. (No,
the list of names will _not_ be released to junk-mail senders. :-)
--dorai
ps: The code is completely free, and users can make all the changes
and/or extensions to it they want. You might want to tell me about
it, if you think it's significant, though.
--
-------------------------------------------------------------------------------
It may be that the gulfs will wash us down;
It may be we shall touch the Happy Isles.
-------------------------------------------------------------------------------
------------------------------
End of Scheme Digest
********************
∂21-Dec-89 2109 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #265
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Dec 89 21:08:56 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA08151; Fri, 22 Dec 89 00:08:01 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Fri, 22 Dec 89 00:06:10 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa23391;
22 Dec 89 0:05 EST
Date: 22 DEC 89 00:03:38 EST
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.lcs.mit.edu>
Subject: Scheme Digest #265
To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Message-Id: <8912220005.aa23391@mintaka.lcs.mit.edu>
Scheme Digest #265 22 DEC 89 00:03:38 EST
Today's Topics:
Prolog interpreter in LISP wanted
----------------------------------------------------------------------
Date: 21 Dec 89 19:47:43 GMT
From: Dorai Sitaram <titan!dorai@rice.edu>
Subject: Re: Prolog interpreter in LISP wanted
Message-Id: <3932@brazos.Rice.edu>
In article <3841@brazos.Rice.edu> dorai@titan.rice.edu (Dorai Sitaram) writes:
>convenient to all concerned if I made it ftp'able from Rice, rather
>than clog the net.
>
>Procedure: ftp titan.rice.edu (as anonymous)
> get public/slog.sh
>
>slog.sh is a shar file, and contains two implementation files (slog.ss
Drew Adams of Laboratoires de Marcoussis, France, very graciously
informs me that the name "slog" is already used and probably
copyrighted for a functional/logic language developed by his lab since
1984.
To avoid complications, I've changed the name of the Prolog-in-Scheme
embedding to "schelog," and hopefully this is a safe name. The file
to ftp is now schelog.sh, but I've retained a soft link to it called
slog.sh, so my previous instructions still remain valid for would-be
ftp'ers.
My thanks to Drew for letting me know. By the way, "schelog" is
pronounced "Ski Lodge," of course.
--dorai
--
-------------------------------------------------------------------------------
It may be that the gulfs will wash us down;
It may be we shall touch the Happy Isles.
-------------------------------------------------------------------------------
------------------------------
End of Scheme Digest
********************
∂22-Dec-89 2222 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #266
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Dec 89 22:22:32 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA20956; Sat, 23 Dec 89 01:21:50 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Sat, 23 Dec 89 01:20:05 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa07675;
23 Dec 89 0:37 EST
Date: 23 DEC 89 00:03:43 EST
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.lcs.mit.edu>
Subject: Scheme Digest #266
To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Message-Id: <8912230037.aa07675@mintaka.lcs.mit.edu>
Scheme Digest #266 23 DEC 89 00:03:43 EST
Today's Topics:
----------------------------------------------------------------------
From: attmail!uucp@att.att.com
Date: Fri Dec 22 12:32:22 EST 1989
Message-ID: <8912221307.aa17206@mintaka.lcs.mit.edu>
Received: from attbl by attmail; Fri Dec 22 17:32 GMT 1989
>From arpa!CUNYVM.CUNY.EDU!Scheme%mc.lcs.mit.edu%mintaka.lcs.mit.edu Fri Dec 22 00:03:38 EST 1989 remote from attbl
Received: from SCF.FUNDP.AC.BE by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 4775; Fri, 22 Dec 89 10:20:29 EDT
Received: by BNANDP11 (Mailer R2.02A) id 2981; Fri, 22 Dec 89 12:41:52 +0100
Date: Fri, 22 Dec 89 00:03:38 EST
Reply-To: Scheme%mc.lcs.mit.edu%mintaka.lcs.mit.edu@CUNYVM.CUNY.EDU
Sender: Scheme Programming Language <SCHEME%BNANDP11.BITNET@CUNYVM.CUNY.EDU>
From: attbl!arpa!CUNYVM.CUNY.EDU!Scheme%mc.lcs.mit.edu%mintaka.lcs.mit.edu (Automatic Scheme Digestifier)
<Scheme-Request%mc.lcs.mit.edu@MINTAKA.LCS.MIT.EDU>
Subject: Scheme Digest #265
Comments: To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
To: ICSUG TEST GROUP
<attmail!mhs!envoy!ICS.TEST/PN=_TEST_GROUP@ATT.ATT.COM>
Scheme Digest #265 22 DEC 89 00:03:38 EST
Today's Topics:
Prolog interpreter in LISP wanted
----------------------------------------------------------------------
Date: 21 Dec 89 19:47:43 GMT
From: Dorai Sitaram <titan!dorai@rice.edu>
Subject: Re: Prolog interpreter in LISP wanted
Message-Id: <3932@brazos.Rice.edu>
In article <3841@brazos.Rice.edu> dorai@titan.rice.edu (Dorai Sitaram) writes:
>convenient to all concerned if I made it ftp'able from Rice, rather
>than clog the net.
>
>Procedure: ftp titan.rice.edu (as anonymous)
> get public/slog.sh
>
>slog.sh is a shar file, and contains two implementation files (slog.ss
Drew Adams of Laboratoires de Marcoussis, France, very graciously
informs me that the name "slog" is already used and probably
copyrighted for a functional/logic language developed by his lab since
1984.
To avoid complications, I've changed the name of the Prolog-in-Scheme
embedding to "schelog," and hopefully this is a safe name. The file
to ftp is now schelog.sh, but I've retained a soft link to it called
slog.sh, so my previous instructions still remain valid for would-be
ftp'ers.
My thanks to Drew for letting me know. By the way, "schelog" is
pronounced "Ski Lodge," of course.
--dorai
--
-------------------------------------------------------------------------------
It may be that the gulfs will wash us down;
It may be we shall touch the Happy Isles.
-------------------------------------------------------------------------------
------------------------------
End of Scheme Digest
********************
------------------------------
End of Scheme Digest
********************
∂27-Dec-89 2112 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #267
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 27 Dec 89 21:12:39 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA25935; Thu, 28 Dec 89 00:12:13 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Thu, 28 Dec 89 00:10:04 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa24663;
28 Dec 89 0:06 EST
Date: 28 DEC 89 00:03:49 EST
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.lcs.mit.edu>
Subject: Scheme Digest #267
To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Message-Id: <8912280006.aa24663@mintaka.lcs.mit.edu>
Scheme Digest #267 28 DEC 89 00:03:49 EST
Today's Topics:
Texas Instruments PC Scheme
----------------------------------------------------------------------
Date: 24 Dec 89 03:53:20 GMT
From: Peter C Olsen <super!pcolsen@uunet.uu.net>
Subject: Texas Instruments PC Scheme
Message-Id: <17909@super.ORG>
Can anyone tell me how to communicate with Texas Instruments about
their PC Scheme? I've had V3.0 for two years, and reported two bugs ---
both of which have been corrected in supsequent releases. Unfortunately,
I found this out only by accident --- I used another computer with V3.03.
I've written TI twice about upgrades, and they have yet to answer. Are they
still in business???!!?
Peter Olsen pcolsen@super.org
------------------------------
End of Scheme Digest
********************
∂29-Dec-89 0048 @zurich.ai.mit.edu,@mc.lcs.mit.edu,@zermatt.lcs.mit.edu:ziggy@hx.lcs.mit.edu Format descriptors in NUMBER->STRING ?
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 29 Dec 89 00:48:02 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA06650; Fri, 29 Dec 89 03:42:46 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Fri, 29 Dec 89 03:41:03 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa09421;
29 Dec 89 3:34 EST
Received: from ZERMATT.LCS.MIT.EDU (CHAOS 17316) by MC.LCS.MIT.EDU; 29 Dec 89 03:34:32 EST
Received: from HX.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via INTERNET with SMTP id 1392; 29 Dec 89 03:33:20 EST
Received: by hx.LCS.MIT.EDU (5.51/4.7); Fri, 29 Dec 89 03:28:42 EST
Date: Fri, 29 Dec 89 03:28:42 EST
From: "Michael R. Blair" <ziggy@hx.lcs.mit.edu>
Message-Id: <8912290828.AA01623@hx.LCS.MIT.EDU>
To: rrrs-authors@zermatt.lcs.mit.edu
Subject: Format descriptors in NUMBER->STRING ?
In the Revised 3.99 Report, why were format descriptors replaced by mere
<radix>? That is,
(NUMBER->STRING number radix) vs (NUMBER->STRING number format)
I don't object to the left form so long as the right form is also an essential
procedure. Why do I care? Maybe I don't... so long as you explain to me how I
can get the precise control over FIX/FLO/SCI that I had with formats, without
having to write some non-trivial string frobbing procedures of my own.
(Uhm...this includes the possibility of separately controlling say the real
and imaginary parts of a rectangular number embedded arbitrarily deep in some
other aggregate number). Point is, this seems a mongo ducky hack for frobbing
with scientific numbers... I would hate to lose such a boon.
Was this ever voted on, for instance at an authors meeting which I missed,
or was this the result of editorial oversight?
~Ziggy
∂29-Dec-89 1336 cph@zurich.ai.mit.edu Format descriptors in NUMBER->STRING ?
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 29 Dec 89 13:36:24 PST
Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.0/AI-4.10) id AA12114; Fri, 29 Dec 89 16:31:38 EST
Received: from localhost by zurich.ai.mit.edu; Fri, 29 Dec 89 16:29:53 est
Date: Fri, 29 Dec 89 16:29:53 est
From: cph@zurich.ai.mit.edu (Chris Hanson)
Message-Id: <8912292129.AA01758@zurich.ai.mit.edu>
To: ziggy@hx.lcs.mit.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: "Michael R. Blair"'s message of Fri, 29 Dec 89 03:28:42 EST <8912290828.AA01623@hx.LCS.MIT.EDU>
Subject: Format descriptors in NUMBER->STRING ?
Date: Fri, 29 Dec 89 03:28:42 EST
From: "Michael R. Blair" <ziggy@hx.lcs.mit.edu>
In the Revised 3.99 Report, why were format descriptors replaced by mere
<radix>? That is,
(NUMBER->STRING number radix) vs (NUMBER->STRING number format)
I don't object to the left form so long as the right form is also an essential
procedure. Why do I care? Maybe I don't... so long as you explain to me how I
can get the precise control over FIX/FLO/SCI that I had with formats, without
having to write some non-trivial string frobbing procedures of my own.
Was this ever voted on, for instance at an authors meeting which I missed,
or was this the result of editorial oversight?
This change was requested by the IEEE editors. The reason for the
request was that (1) it was felt that this was a baroque method for
accomplishing this, somewhat like `format' of Common Lisp, and (2) to
our knowledge, no one had implemented any of the formats except for
`heur'.
Because no one had implemented these procedures, the "precise control"
that you had with the format arguments is exactly what you have now.
It was proposed at that time that a set of formatting procedures be
implemented and submitted to the yellow pages, or perhaps to be added
to the RnRS. There would be one procedure for each type of format,
avoiding the issue of designing a "format language" to represent the
procedure calls.
∂02-Jan-90 0818 dyb@iuvax.cs.indiana.edu Re: Format descriptors in NUMBER->STRING ?
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 2 Jan 90 08:18:37 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA21404; Tue, 2 Jan 90 11:14:47 EST
Received: from iuvax.cs.indiana.edu (iuvax.cs.indiana.edu) by zurich.ai.mit.edu; Tue, 2 Jan 90 11:13:45 est
Message-Id: <9001021613.AA00036@zurich.ai.mit.edu>
Received: by iuvax.cs.indiana.edu
Date: Tue, 2 Jan 90 11:12:13 -0500
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
To: cph@zurich.ai.mit.edu, ziggy@hx.lcs.mit.edu
Subject: Re: Format descriptors in NUMBER->STRING ?
Cc: rrrs-authors@zurich.ai.mit.edu
> Date: Fri, 29 Dec 89 16:29:53 est
> From: cph@zurich.ai.mit.edu (Chris Hanson)
> Date: Fri, 29 Dec 89 03:28:42 EST
> From: "Michael R. Blair" <ziggy@hx.lcs.mit.edu>
>
> In the Revised 3.99 Report, why were format descriptors replaced by mere
> <radix>? That is,
>
> (NUMBER->STRING number radix) vs (NUMBER->STRING number format)
>
> Was this ever voted on, for instance at an authors meeting which I missed,
> or was this the result of editorial oversight?
>
> This change was requested by the IEEE editors. The reason for the
> request was that (1) it was felt that this was a baroque method for
> accomplishing this, somewhat like `format' of Common Lisp, and (2) to
> our knowledge, no one had implemented any of the formats except for
> `heur'.
This topic also came up in the Snowbird authors' meeting. There was
general agreement in that meeting that the format language was too
baroque, and no one seemed to have implemented it fully at the time. A
committee consisting of Alan Bawden, Gerry Sussman, and myself was
directed to deal with the problem, and we recommended that the format
argument be dropped.
Kent
∂02-Jan-90 1414 @zurich.ai.mit.edu,@mc.lcs.mit.edu,@zermatt.lcs.mit.edu:ziggy@hx.lcs.mit.edu RE↑2: Format Descriptors
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 2 Jan 90 14:14:36 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA26483; Tue, 2 Jan 90 17:11:42 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Tue, 2 Jan 90 17:11:16 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa19824;
2 Jan 90 17:10 EST
Received: from ZERMATT.LCS.MIT.EDU (CHAOS 17316) by MC.LCS.MIT.EDU; 2 Jan 90 17:09:01 EST
Received: from HX.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via INTERNET with SMTP id 1882; 2 Jan 90 17:10:08 EST
Received: by hx.LCS.MIT.EDU (5.51/4.7); Tue, 2 Jan 90 17:04:02 EST
Date: Tue, 2 Jan 90 17:04:02 EST
From: "Michael R. Blair" <ziggy@hx.lcs.mit.edu>
Message-Id: <9001022204.AA05609@hx.LCS.MIT.EDU>
To: rrrs-authors@zermatt.lcs.mit.edu
Subject: RE↑2: Format Descriptors
OK. Sorry to have been alarmist. Admittedly,
I recall now that this was mentioned but I
just didn't recall that it was settled.
Thanks for your patient replies. ~Ziggy
∂05-Jan-90 0109 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #268
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 5 Jan 90 01:09:49 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA14005; Fri, 5 Jan 90 00:14:07 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Fri, 5 Jan 90 00:13:33 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa02713;
5 Jan 90 0:13 EST
Date: 5 JAN 90 00:11:45 EST
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.lcs.mit.edu>
Subject: Scheme Digest #268
To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Message-Id: <9001050013.aa02713@mintaka.lcs.mit.edu>
Scheme Digest #268 5 JAN 90 00:11:45 EST
Today's Topics:
Mac implementations
exit on Schemes for Unix
----------------------------------------------------------------------
Date: 4 Jan 90 05:52:29 GMT
From: Andres Moreno <moreno@UMN-CS.CS.UMN.EDU>
Subject: Mac implementations
Message-Id: <18025@umn-cs.CS.UMN.EDU>
Does anybody have any experience with MacScheme? Do you recomend to look
into another dialect of LISP for this machine? Does anyone know anything
about ExperLOGO?
I'd appreciate any suggestions regarding LISPs and Schemes for PCs or Macs
(or any other small machine costing less than $4,000) since I am in the
market for a new computer.
Thanks, Andres F. Moreno
------------------------------
From: ramsdell@linus.mitre.org
Message-Id: <9001041217.AA11268@huxley.mitre.org>
Subject: exit on Schemes for Unix
Date: Thu, 04 Jan 90 07:17:56 EST
Please remember, Scheme is not always used interactively!!!
To: Implementors of Scheme on Unix
Subject: Let your Scheme's exit status reflect the current break level.
I would like to encourage all Scheme Implementors which target Unix to
add a fairly simple feature. When the exit command is called with no
arguments, or when there is nothing more to read from standard input,
the Scheme interpreter process should set the status bits returned to
the parent process to the break level. When there has been no errors,
that status should be set to zero, the Unix convention for successful
completion. A non-zero break level indicates an error, and that state
should be reflected by a non-zero exit status.
For just one example of where this might be useful, consider the
writing of Makefiles. Suppose we have the rule:
.scm.sobj:
echo "(compile-file \"$*.sobj\")" | scheme
The rule will fail when the compiler detects an error.
John
------------------------------
End of Scheme Digest
********************
∂05-Jan-90 2249 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #269
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 5 Jan 90 22:49:07 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA29977; Sat, 6 Jan 90 01:44:27 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Sat, 6 Jan 90 01:43:53 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa04600;
6 Jan 90 1:13 EST
Date: 6 JAN 90 00:11:48 EST
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.lcs.mit.edu>
Subject: Scheme Digest #269
To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Message-Id: <9001060113.aa04600@mintaka.lcs.mit.edu>
Scheme Digest #269 6 JAN 90 00:11:48 EST
Today's Topics:
TI PC-Scheme (was (none))
mac scheme implementations
exit on Schemes for Unix
mac scheme implementations
----------------------------------------------------------------------
From: attmail!uucp@att.att.com
Date: Thu Jan 4 21:46:24 EST 1990
Message-ID: <9001050058.aa04151@mintaka.lcs.mit.edu>
Received: from attbl by attmail; Fri Jan 5 02:46 GMT 1990
>From arpa!CUNYVM.CUNY.EDU!Scheme%mc.lcs.mit.edu%mintaka.lcs.mit.edu Thu Dec 28 00:03:49 EST 1989 remote from attbl
Received: from SCF.FUNDP.AC.BE by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 7538; Thu, 04 Jan 90 17:47:53 EDT
Received: by BNANDP11 (Mailer R2.02A) id 6674; Thu, 04 Jan 90 23:46:11 +0100
Date: Thu, 28 Dec 89 00:03:49 EST
Reply-To: Scheme%mc.lcs.mit.edu%mintaka.lcs.mit.edu@CUNYVM.CUNY.EDU
Sender: Scheme Programming Language <SCHEME%BNANDP11.BITNET@CUNYVM.CUNY.EDU>
From: attbl!arpa!CUNYVM.CUNY.EDU!Scheme%mc.lcs.mit.edu%mintaka.lcs.mit.edu (Automatic Scheme Digestifier)
<Scheme-Request%mc.lcs.mit.edu@MINTAKA.LCS.MIT.EDU>
Subject: Scheme Digest #267
Comments: To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
To: ICSUG TEST GROUP
<attmail!mhs!envoy!ICS.TEST/PN=_TEST_GROUP@ATT.ATT.COM>
Scheme Digest #267 28 DEC 89 00:03:49 EST
Today's Topics:
Texas Instruments PC Scheme
----------------------------------------------------------------------
Date: 24 Dec 89 03:53:20 GMT
From: Peter C Olsen <super!pcolsen@uunet.uu.net>
Subject: Texas Instruments PC Scheme
Message-Id: <17909@super.ORG>
Can anyone tell me how to communicate with Texas Instruments about
their PC Scheme? I've had V3.0 for two years, and reported two bugs ---
both of which have been corrected in supsequent releases. Unfortunately,
I found this out only by accident --- I used another computer with V3.03.
I've written TI twice about upgrades, and they have yet to answer. Are they
still in business???!!?
Peter Olsen pcolsen@super.org
------------------------------
End of Scheme Digest
********************
------------------------------
From: attmail!uucp@att.att.com
Date: Fri Jan 5 01:04:02 EST 1990
Message-ID: <9001050216.aa06444@mintaka.lcs.mit.edu>
Received: from attbl by attmail; Fri Jan 5 06:03 GMT 1990
>From arpa!CUNYVM.CUNY.EDU!Scheme%mc.lcs.mit.edu%mintaka.lcs.mit.edu Fri Jan 5 00:11:45 EST 1990 remote from attbl
Received: from SCF.FUNDP.AC.BE by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 9863; Fri, 05 Jan 90 00:43:57 EDT
Received: by BNANDP11 (Mailer R2.02A) id 7403; Fri, 05 Jan 90 06:35:18 +0100
Date: Fri, 5 Jan 90 00:11:45 EST
Reply-To: Scheme%mc.lcs.mit.edu%mintaka.lcs.mit.edu@CUNYVM.CUNY.EDU
Sender: Scheme Programming Language <SCHEME%BNANDP11.BITNET@CUNYVM.CUNY.EDU>
From: attbl!arpa!CUNYVM.CUNY.EDU!Scheme%mc.lcs.mit.edu%mintaka.lcs.mit.edu (Automatic Scheme Digestifier)
<Scheme-Request%mc.lcs.mit.edu@MINTAKA.LCS.MIT.EDU>
Subject: Scheme Digest #268
Comments: To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
To: ICSUG TEST GROUP
<attmail!mhs!envoy!ICS.TEST/PN=_TEST_GROUP@ATT.ATT.COM>
Scheme Digest #268 5 JAN 90 00:11:45 EST
Today's Topics:
Mac implementations
exit on Schemes for Unix
----------------------------------------------------------------------
Date: 4 Jan 90 05:52:29 GMT
From: Andres Moreno <moreno@UMN-CS.CS.UMN.EDU>
Subject: Mac implementations
Message-Id: <18025@umn-cs.CS.UMN.EDU>
Does anybody have any experience with MacScheme? Do you recomend to look
into another dialect of LISP for this machine? Does anyone know anything
about ExperLOGO?
I'd appreciate any suggestions regarding LISPs and Schemes for PCs or Macs
(or any other small machine costing less than $4,000) since I am in the
market for a new computer.
Thanks, Andres F. Moreno
------------------------------
From: ramsdell@linus.mitre.org
Message-Id: <9001041217.AA11268@huxley.mitre.org>
Subject: exit on Schemes for Unix
Date: Thu, 04 Jan 90 07:17:56 EST
Please remember, Scheme is not always used interactively!!!
To: Implementors of Scheme on Unix
Subject: Let your Scheme's exit status reflect the current break level.
I would like to encourage all Scheme Implementors which target Unix to
add a fairly simple feature. When the exit command is called with no
arguments, or when there is nothing more to read from standard input,
the Scheme interpreter process should set the status bits returned to
the parent process to the break level. When there has been no errors,
that status should be set to zero, the Unix convention for successful
completion. A non-zero break level indicates an error, and that state
should be reflected by a non-zero exit status.
For just one example of where this might be useful, consider the
writing of Makefiles. Suppose we have the rule:
.scm.sobj:
echo "(compile-file \"$*.sobj\")" | scheme
The rule will fail when the compiler detects an error.
John
------------------------------
End of Scheme Digest
********************
------------------------------
Date: 5 Jan 90 18:20:59 GMT
From: "David H. West" <samsung!shadooby!umich!itivax!dhw@think.com>
Subject: Re: TI PC-Scheme (was (none))
Message-Id: <4737@itivax.iti.org>
In article <9001050058.aa04151@mintaka.lcs.mit.edu> uucp@attmail.UUCP writes:
|From: Peter C Olsen <super!pcolsen@uunet.uu.net>
|Subject: Texas Instruments PC Scheme
|
|Can anyone tell me how to communicate with Texas Instruments about
|their PC Scheme? [...]
|I've written TI twice about upgrades, and they have yet to answer. Are they
|still in business???!!?
I just called the local TI sales office, and got my 3.0 upgraded
to 3.03 with no trouble at all. They did want the original floppies
back, though.
------------------------------
Message-Id: <9001051959.AA13175@schizo.samsung.com>
Reply-To: gjc@mitech.com
Date: Fri, 5 Jan 90 09:34:13 EDT
From: gjc@mitech.com
Subject: mac scheme implementations
SIOD will run on the Mac, probably with a little modification for
Lightspeed C. anonymous ftp to bu.edu and cd to src/gjc and get
siod-v2.3-shar
Note on interpreters: I tried SABER-C on a SUN-4 with SLIB.C compiled
and SIOD.C interpreted. By running (standard-fib 15) vs. (cfib 15) we
can then test the scheme interpreter speed vs the SABER-C interpreter
speed. Here is the code:
(define (standard-fib x)
(if (< x 2)
x
(+ (standard-fib (- x 1))
(standard-fib (- x 2)))))
LISP cfib(x)
LISP x;
{if NNULLP(lessp(x,my_two))
return(x);
else
return(plus(cfib(difference(x,my_one)),
cfib(difference(x,my_two))));}
RESULT: The scheme interpreter is more than 10 times faster (takes less than
1/10'th the time to compute fib(15)) than the SABER-C interpreter.
-gjc
------------------------------
Date: 5 Jan 90 16:38:18 GMT
From: John Gateley <samsung!cs.utexas.edu!sun-barr!newstop!texsun!pollux!ti-csl!m2!gateley@think.com>
Subject: Re: exit on Schemes for Unix
Message-Id: <104546@ti-csl.csc.ti.com>
In article <9001041217.AA11268@huxley.mitre.org> ramsdell@LINUS.MITRE.ORG writes:
>When the exit command is called with no
>arguments, or when there is nothing more to read from standard input,
>the Scheme interpreter process should set the status bits returned to
>the parent process to the break level.
I agree except for one thing:
It should merely set the status bits to a non-zero value (or whatever
restriction Unix percieves as an error).
This allows the scheme program to return more useful error information:
(error 57) where 57 is the error number for directory not found,
John
gateley@m2.csc.ti.com
------------------------------
Date: 5 Jan 90 21:34:11 GMT
From: Scott Hankin <paperboy!sauron!hankin@think.com>
Subject: Re: mac scheme implementations
Message-Id: <2468@paperboy.OSF.ORG>
gjc@mitech.COM writes:
>SIOD will run on the Mac, probably with a little modification for
>Lightspeed C. anonymous ftp to bu.edu and cd to src/gjc and get
>siod-v2.3-shar
Actually, its in users/gjc.
------------------------------
Scott Hankin (hankin@osf.org)
Open Software Foundation
------------------------------
End of Scheme Digest
********************
∂09-Jan-90 2149 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #270
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 9 Jan 90 21:49:18 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA03844; Wed, 10 Jan 90 00:46:24 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Wed, 10 Jan 90 00:45:15 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa07218;
10 Jan 90 0:26 EST
Date: 10 JAN 90 00:00:38 EST
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.lcs.mit.edu>
Subject: Scheme Digest #270
To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Message-Id: <9001100026.aa07218@mintaka.lcs.mit.edu>
Scheme Digest #270 10 JAN 90 00:00:38 EST
Today's Topics:
t3.1 on Apollo SR10
Pretty Printer Source Code
Compiling Scheme (Summary)
----------------------------------------------------------------------
Date: 8 Jan 90 19:02:12 GMT
From: Patrick Logan <tektronix!sequent!mntgfx!plogan@bloom-beacon.mit.edu>
Subject: t3.1 on Apollo SR10
Message-Id: <1990Jan8.190212.354@mentor.com>
I have ftp'd t3.1 from MIT and am trying to get it running on Apollo
SR10. My current problem is this:
% bl st.image
error loading t: seeking for data section -
bad length (process manager/mapped segment manager)
Has anyone run into this? Have you fixed it?
More information:
-rwxr-xr-x+ 1 plogan sim 8530 Feb 24 1989 bl
-rwxr-xr-x+ 1 plogan sim 4456 Feb 24 1989 float.bin
-rwxr-xr-x+ 1 plogan sim 2428 Feb 27 1989 float.pas
-rwxr-xr-x+ 1 plogan sim 2886648 Feb 24 1989 st.image
This is curiously not COFF:
% file bl
bl: obj apollo type obj executable (OBJ)
This is curious too. What is this supposed to be?
% file ../apollo_sr10_bl
../apollo_sr10_bl: unstruct data
% ll ../apollo_sr10_bl
-rwxr-xr-x+ 1 plogan sim 8530 Jan 7 14:19 ../apollo_sr10_bl
If anyone can offer any help, I'd appreciate it. Until then, I'll be
debugging...
--
Patrick Logan | ...!{decwrl,sequent,tessi}!mntgfx!plogan
Mentor Graphics Corporation | plogan@pdx.MENTOR.COM
Beaverton, Oregon |
------------------------------
Date: 10 Jan 90 02:50:49 GMT
From: Jason Coughlin <zaphod.mps.ohio-state.edu!rpi!image.soe.clarkson.edu!jk0@think.com>
Subject: Pretty Printer Source Code
Message-Id: <1990Jan10.025049.28982@sun.soe.clarkson.edu>
Does anyone have source code to a pretty printer for LISP or Scheme?
LISP or Scheme code would be nice, but beggars can't be choosers :-)!
Either email or post. Thank you!
--
Jason Coughlin ( jk0@sun.soe.clarkson.edu , jk0@clutx )
"Every jumbled pile of person has a thinking part that wonders what the
part that isn't thinking isn't thinking of." - They Might Be Giants
------------------------------
Date: 10 Jan 90 02:48:59 GMT
From: Jason Coughlin <zaphod.mps.ohio-state.edu!rpi!image.soe.clarkson.edu!jk0@think.com>
Subject: Compiling Scheme (Summary)
Message-Id: <1990Jan10.024859.28865@sun.soe.clarkson.edu>
This is quite a hot issue so I thought I'd post a summary of what I
received. Thanks to everyone who gave me a lead!
The best I've found so far is in _Structure and Interpretation and
Computer Programs_ by Harold Abelson, Gerald Jay Sussman, and Julie
Sussman. This is a GREAT book that IMHO should be used to teach
undergrad Programming Languages courses.
Anyway, enjoy!
From: Ozan Yigit <oz@nexus.yorku.ca>
* The best reference on compiling scheme appears to be SIofCP
of Abelson & Sussman.
* Also check out xscheme
* Allen's "Anatomy Of Lisp" also has a
From: Matthias Felleisen <matthias@rice.edu>
* You may want to look at a paper by Will Clinger in the proceedings of
Lisp & Functional Programming 1984. His paper on deriving a byte-code
compiler for Scheme has some title like "An exercise in denotational
semantics." The resulting system, Scheme 311, was used at Indiana for
a few years.
* If you want the code of a byte-code compiler for unix
machines and you have FRANZ LISP, write to nlg@indiana.iuvax.cs.edu
and ask whether they still distribute Scheme84. I have a revision of
Scheme84, called Scheme88, that is pretty much the same thing (a bit
cleaner inside, but not much) except that it uses Common Lisp for the
interpretation of byte-code.
From: Denys Duchier <duchier-denys@YALE.ARPA>
* Check Guy Steele's thesis (RABBIT a compiler for scheme) (MIT)
* also David Krantz's thesis (ORBIT, an optimizing compiler for
scheme) (YALE).
From: Simon Leinen <simon%opal.cs.tu-berlin.de%tub.BITNET@clvm.clarkson.edu>
here comes a list of references to books and articles about the
problem of compiling Scheme or Lisp. I don't know whether it is
correct `refer' syntax. I distributed the following keywords of my
own creation:
scheme - concerned with scheme rather than lisp
lisp - concerned with lisp rather than scheme
commonlisp - maclisp/common lisp (more like scheme)
standardlisp - psl/cambridge etc. (less like scheme, e.g. no closures)
compiler - all articles deal with compilation (more or less)
%A R. R. Kessler
%A J. C. Peterson
%A H. Carr
%A G.P. Duggan
%A J. Knell
%A J.J. Krohnfeldt
%T EPIC - a retargetable, highly optimizing Lisp compiler
%J Proc. Sigplan 1986 Sym. on Compiler Construction
%D June 1986
%C New York
%P 118-130
%K lisp standardlisp compiler
%A D. Kranz
%A R. Kelsey
%A J. Rees
%A P. Hudak
%A J. Philbin
%A N. Adams
%T ORBIT: an optimizing compiler for Scheme
%J Proc. Sigplan '86 Sym. on Compiler Construction
%D June 1986
%C New York
%P 219-233
%K scheme compiler
%A G. L. Steele Jr.
%T RABBIT: a compiler for Scheme
%R AI Memo 474
%C Massachusetts Institute of Technology
%D May 1978
%K scheme compiler
%A R. A. Brooks
%A R. P. Gabriel
%A G. L. Steele Jr.
%T An optimizing compiler for lexicaly scoped LISP
%J Proc. 1982 Sym. on Compiler Construction
%D June 1982
%V 17
%N 4
%K lisp commonlisp compiler
%A R. A. Brooks
%A R. P. Gabriel
%A G. L. Steele Jr.
%T S-1 Common Lisp implementation
%J Proc. 1982 Sym. on Lisp and Functional Programming
%D August 1982
%C New York
%K lisp commonlisp compiler
%A O. Shivers
%T Control flow analysis in Scheme
%J Proc. Sigplan 1988 Conf. on Programming Language Design and Implementation
%D 1988
%C New York
%K scheme compiler
%A R. A. Brooks
%A D. B. Posner
%A J. L. McDonald
%A J. L. White
%A E. Benson
%A R. P. Gabriel
%T Design of an optimizing, dynamically retargetable compiler for Common Lisp
%K lisp commonlisp compiler
%A R. P. Gabriel
%T Performance and evaluation of Lisp systems
%I MIT Press
%C Cambridge, Mass.
%D 1985
%K lisp compiler
%A M. L. Griss
%A A. C. Hearn
%T A portable LISP compiler
%J Software Practice and Experience
%N 11
%D 1981
%P 541-605
%K lisp standardlisp compiler
--
Jason Coughlin ( jk0@sun.soe.clarkson.edu , jk0@clutx )
"Every jumbled pile of person has a thinking part that wonders what the
part that isn't thinking isn't thinking of." - They Might Be Giants
------------------------------
End of Scheme Digest
********************
∂10-Jan-90 2145 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #271
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 10 Jan 90 21:45:05 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA25963; Thu, 11 Jan 90 00:40:40 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Thu, 11 Jan 90 00:40:04 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa02008;
11 Jan 90 0:25 EST
Date: 11 JAN 90 00:00:37 EST
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.lcs.mit.edu>
Subject: Scheme Digest #271
To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Message-Id: <9001110025.aa02008@mintaka.lcs.mit.edu>
Scheme Digest #271 11 JAN 90 00:00:37 EST
Today's Topics:
Compiling Scheme (Summary)
Texas Instruments PC Scheme
----------------------------------------------------------------------
From: attmail!uucp@att.att.com
Date: Wed Jan 10 05:39:37 EST 1990
Message-ID: <9001100605.aa19149@mintaka.lcs.mit.edu>
Received: from attbl by attmail; Wed Jan 10 10:39 GMT 1990
>From arpa!CUNYVM.CUNY.EDU!Scheme%mc.lcs.mit.edu%mintaka.lcs.mit.edu Wed Jan 10 00:00:38 EST 1990 remote from attbl
Received: from SCF.FUNDP.AC.BE by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 9145; Wed, 10 Jan 90 03:38:55 EDT
Received: by BNANDP11 (Mailer R2.02A) id 5272; Wed, 10 Jan 90 09:26:28 +0100
Date: Wed, 10 Jan 90 00:00:38 EST
Reply-To: Scheme%mc.lcs.mit.edu%mintaka.lcs.mit.edu@CUNYVM.CUNY.EDU
Sender: Scheme Programming Language <SCHEME%BNANDP11.BITNET@CUNYVM.CUNY.EDU>
From: attbl!arpa!CUNYVM.CUNY.EDU!Scheme%mc.lcs.mit.edu%mintaka.lcs.mit.edu (Automatic Scheme Digestifier)
<Scheme-Request%mc.lcs.mit.edu@MINTAKA.LCS.MIT.EDU>
Subject: Scheme Digest #270
Comments: To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
To: ICSUG TEST GROUP
<attmail!mhs!envoy!ICS.TEST/PN=_TEST_GROUP@ATT.ATT.COM>
Scheme Digest #270 10 JAN 90 00:00:38 EST
Today's Topics:
t3.1 on Apollo SR10
Pretty Printer Source Code
Compiling Scheme (Summary)
----------------------------------------------------------------------
Date: 8 Jan 90 19:02:12 GMT
From: Patrick Logan <tektronix!sequent!mntgfx!plogan@bloom-beacon.mit.edu>
Subject: t3.1 on Apollo SR10
Message-Id: <1990Jan8.190212.354@mentor.com>
I have ftp'd t3.1 from MIT and am trying to get it running on Apollo
SR10. My current problem is this:
% bl st.image
error loading t: seeking for data section -
bad length (process manager/mapped segment manager)
Has anyone run into this? Have you fixed it?
More information:
-rwxr-xr-x+ 1 plogan sim 8530 Feb 24 1989 bl
-rwxr-xr-x+ 1 plogan sim 4456 Feb 24 1989 float.bin
-rwxr-xr-x+ 1 plogan sim 2428 Feb 27 1989 float.pas
-rwxr-xr-x+ 1 plogan sim 2886648 Feb 24 1989 st.image
This is curiously not COFF:
% file bl
bl: obj apollo type obj executable (OBJ)
This is curious too. What is this supposed to be?
% file ../apollo_sr10_bl
../apollo_sr10_bl: unstruct data
% ll ../apollo_sr10_bl
-rwxr-xr-x+ 1 plogan sim 8530 Jan 7 14:19 ../apollo_sr10_bl
If anyone can offer any help, I'd appreciate it. Until then, I'll be
debugging...
--
Patrick Logan | ...!{decwrl,sequent,tessi}!mntgfx!plogan
Mentor Graphics Corporation | plogan@pdx.MENTOR.COM
Beaverton, Oregon |
------------------------------
Date: 10 Jan 90 02:50:49 GMT
From: Jason Coughlin
<zaphod.mps.ohio-state.edu!rpi!image.soe.clarkson.edu!jk0@think.com>
Subject: Pretty Printer Source Code
Message-Id: <1990Jan10.025049.28982@sun.soe.clarkson.edu>
Does anyone have source code to a pretty printer for LISP or Scheme?
LISP or Scheme code would be nice, but beggars can't be choosers :-)!
Either email or post. Thank you!
--
Jason Coughlin ( jk0@sun.soe.clarkson.edu , jk0@clutx )
"Every jumbled pile of person has a thinking part that wonders what the
part that isn't thinking isn't thinking of." - They Might Be Giants
------------------------------
Date: 10 Jan 90 02:48:59 GMT
From: Jason Coughlin
<zaphod.mps.ohio-state.edu!rpi!image.soe.clarkson.edu!jk0@think.com>
Subject: Compiling Scheme (Summary)
Message-Id: <1990Jan10.024859.28865@sun.soe.clarkson.edu>
This is quite a hot issue so I thought I'd post a summary of what I
received. Thanks to everyone who gave me a lead!
The best I've found so far is in _Structure and Interpretation and
Computer Programs_ by Harold Abelson, Gerald Jay Sussman, and Julie
Sussman. This is a GREAT book that IMHO should be used to teach
undergrad Programming Languages courses.
Anyway, enjoy!
From: Ozan Yigit <oz@nexus.yorku.ca>
* The best reference on compiling scheme appears to be SIofCP
of Abelson & Sussman.
* Also check out xscheme
* Allen's "Anatomy Of Lisp" also has a
From: Matthias Felleisen <matthias@rice.edu>
* You may want to look at a paper by Will Clinger in the proceedings of
Lisp & Functional Programming 1984. His paper on deriving a byte-code
compiler for Scheme has some title like "An exercise in denotational
semantics." The resulting system, Scheme 311, was used at Indiana for
a few years.
* If you want the code of a byte-code compiler for unix
machines and you have FRANZ LISP, write to nlg@indiana.iuvax.cs.edu
and ask whether they still distribute Scheme84. I have a revision of
Scheme84, called Scheme88, that is pretty much the same thing (a bit
cleaner inside, but not much) except that it uses Common Lisp for the
interpretation of byte-code.
From: Denys Duchier <duchier-denys@YALE.ARPA>
* Check Guy Steele's thesis (RABBIT a compiler for scheme) (MIT)
* also David Krantz's thesis (ORBIT, an optimizing compiler for
scheme) (YALE).
From: Simon Leinen <simon%opal.cs.tu-berlin.de%tub.BITNET@clvm.clarkson.edu>
here comes a list of references to books and articles about the
problem of compiling Scheme or Lisp. I don't know whether it is
correct `refer' syntax. I distributed the following keywords of my
own creation:
scheme - concerned with scheme rather than lisp
lisp - concerned with lisp rather than scheme
commonlisp - maclisp/common lisp (more like scheme)
standardlisp - psl/cambridge etc. (less like scheme, e.g. no closures)
compiler - all articles deal with compilation (more or less)
%A R. R. Kessler
%A J. C. Peterson
%A H. Carr
%A G.P. Duggan
%A J. Knell
%A J.J. Krohnfeldt
%T EPIC - a retargetable, highly optimizing Lisp compiler
%J Proc. Sigplan 1986 Sym. on Compiler Construction
%D June 1986
%C New York
%P 118-130
%K lisp standardlisp compiler
%A D. Kranz
%A R. Kelsey
%A J. Rees
%A P. Hudak
%A J. Philbin
%A N. Adams
%T ORBIT: an optimizing compiler for Scheme
%J Proc. Sigplan '86 Sym. on Compiler Construction
%D June 1986
%C New York
%P 219-233
%K scheme compiler
%A G. L. Steele Jr.
%T RABBIT: a compiler for Scheme
%R AI Memo 474
%C Massachusetts Institute of Technology
%D May 1978
%K scheme compiler
%A R. A. Brooks
%A R. P. Gabriel
%A G. L. Steele Jr.
%T An optimizing compiler for lexicaly scoped LISP
%J Proc. 1982 Sym. on Compiler Construction
%D June 1982
%V 17
%N 4
%K lisp commonlisp compiler
%A R. A. Brooks
%A R. P. Gabriel
%A G. L. Steele Jr.
%T S-1 Common Lisp implementation
%J Proc. 1982 Sym. on Lisp and Functional Programming
%D August 1982
%C New York
%K lisp commonlisp compiler
%A O. Shivers
%T Control flow analysis in Scheme
%J Proc. Sigplan 1988 Conf. on Programming Language Design and Implementation
%D 1988
%C New York
%K scheme compiler
%A R. A. Brooks
%A D. B. Posner
%A J. L. McDonald
%A J. L. White
%A E. Benson
%A R. P. Gabriel
%T Design of an optimizing, dynamically retargetable compiler for Common Lisp
%K lisp commonlisp compiler
%A R. P. Gabriel
%T Performance and evaluation of Lisp systems
%I MIT Press
%C Cambridge, Mass.
%D 1985
%K lisp compiler
%A M. L. Griss
%A A. C. Hearn
%T A portable LISP compiler
%J Software Practice and Experience
%N 11
%D 1981
%P 541-605
%K lisp standardlisp compiler
--
Jason Coughlin ( jk0@sun.soe.clarkson.edu , jk0@clutx )
"Every jumbled pile of person has a thinking part that wonders what the
part that isn't thinking isn't thinking of." - They Might Be Giants
------------------------------
End of Scheme Digest
********************
------------------------------
Date: 10 Jan 90 20:23:20 GMT
From: Ken Dickey <zephyr.ens.tek.com!tekcrl!tekchips!kend@beaver.cs.washington.edu>
Subject: Re: Compiling Scheme (Summary)
Message-Id: <5365@tekcrl.LABS.TEK.COM>
In article <1990Jan10.024859.28865@sun.soe.clarkson.edu> jk0@sun.soe.clarkson.edu (Jason Coughlin) writes:
>This is quite a hot issue so I thought I'd post a summary of what I
>received. Thanks to everyone who gave me a lead!
>
I guess I missed your request. Here are the references I have to
published works on Scheme compilation:
Sussman, Gerald Jay: "LISP, Programming and Implementation",
in "Functional Programming and its Applications"
Eds: Darlington, Henderson, & Turner
Cambridge U Press, 1982
Abelson & Sussman: "Structure and Interpretation of Computer Programs"
MIT Press, 1985
Steele: "RABBIT: A Compiler for SCHEME (A Study in Compiler Optimization)"
MIT AI-TR-474, May 1978
Rosas, Guillermo: "Liar, an Algol-like Compiler for Scheme"
MIT Bachelor's thesis, January 24, 1987
Clinger, Will:"The Scheme 311 Compiler, An Excercise in Denotational Semantics"
1984 Symposium on Lisp and Functional Programming
Bartley & Jensen: "The Implementation of PC Scheme"
Proceedings of the 1986 ACM Conference on Lisp and Functional Programming
Kranz, ... Adams , et al: "Orbit, an Optimizing Compiler for Scheme"
SigPlan Notices V21, #7, July 1986
Wand: "From Interpreter to Compiler: A Representational Derivation"
in "Programs as Data Objects", Springer-Verlag lecture notes 217, 1986.
Feeley & Lapine: "Using Closures for Code Generation"
Computer Languages: V12, #1 1987
Vegdahl & Pleban: "The Runtime Environment for Screme, a Scheme
implementation on the 88000", SIGPLAN Notices, Vol 24 Special Issue, May
1989.
Also, the latest issue of LISP AND SYMBOLIC COMPUTATION which contains
a loooong article on compiling Scheme for parallel machines.
-Ken Dickey
------------------------------
Date: 6 Jan 90 14:09:16 GMT
From: Florian Reichl <snorkelwacker!ira.uka.de!smurf!gopnbg!altger!doitcr!floenz1.UUCP!flo@bloom-beacon.mit.edu>
Subject: Re: Texas Instruments PC Scheme
Message-Id: <1158@doitcr.UUCP>
In article <17909@super.ORG> pcolsen@super.UUCP (Peter C Olsen) writes:
} I found this out only by accident --- I used another computer with V3.03.
} I've written TI twice about upgrades, and they have yet to answer. Are they
} still in business???!!?
Well, they even developed a version 4.0. It is bundled with one of their
expert system shells. But it wasn't developed only by TI. There was
another company working on the code. Perhaps this prevents TI from
distributing version 4.0.
My software dealer here in the Federal Republic of Germany sells version
3.03 for 330 DM. I can give his address to you.
flo@floenz1.doit.sub.org
or via Bitnet: doitcr!floenz1!flo@tmpmbx.uucp
------------------------------
End of Scheme Digest
********************
∂12-Jan-90 0034 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #272
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 12 Jan 90 00:33:52 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA04378; Fri, 12 Jan 90 03:29:28 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Fri, 12 Jan 90 03:28:44 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa23722;
12 Jan 90 1:17 EST
Date: 12 JAN 90 00:01:55 EST
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.lcs.mit.edu>
Subject: Scheme Digest #272
To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Message-Id: <9001120117.aa23722@mintaka.lcs.mit.edu>
Scheme Digest #272 12 JAN 90 00:01:55 EST
Today's Topics:
SIGUCCS CALL for PARTICIPATION
----------------------------------------------------------------------
Date: Thu, 11 Jan 90 14:13 EST
From: Amin Shafie - Univ of Cincinnati Comp Ctr <SHAFIE@ucbeh.san.uc.edu>
Subject: SIGUCCS CALL for PARTICIPATION
Message-id: <F5F94E786DBF00D81C@UCBEH.SAN.UC.EDU>
<--------------------------------------------------------------------
<
< SIGUCCS User Services Conference XVIII
< Call For Participation
<
< New Centerings in Computing Services
<
< September 30 through October 3, 1990
<
< Westin Hotel
< Cincinnati, Ohio
<
<
<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
<<
<<
<<Attention Directors, Managers, Analysts, Consultants, Programmers,
<<Technical Writers, Trainers, and Librarians!
<<
<<The higher education computing scene in the 1990s will present exciting
<<challenges. To accommodate users' needs, computing service organizations
<<are now visibly transforming in function and structure. The widespread
<<adoption of personal computing by all disciplines, the increasing demand
<<for desktop access to shared resources, the growth in demand for
<<supercomputing capabilities, and the proliferation of powerful desktop
<<workstations exert irresistible forces on central computing services.
<<In response, the central site grows exponentially in staff and machinery
<<at one academic institution; at another, the computing center is disbanded
<<to provide distributed computing! At some sites increasing specialization
<<is urged; at others, generalization is required. Regardless of the
<<transforming strategy adopted by an individual institution, one fact
<<seems clear: the user is the center toward which all computing services
<<are directed.
<<
<<SIGUCCS '90 invites you to participate in the examination and discussion
<<of the myriad challenges facing user services professionals as we enter a
<<new decade and of the new centerings computing service organizations are
<<discovering to meet them. Please join us!
<<
<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
<<
<<You can Participate
<<
<< Presentations
<<
<< Papers
<<
<< Panel Discussions
<<
<< Quick Workshops
<<
<< Educational Materials Competition
<<
<< Newsletter Competition
<<
<< Technical Writing Competition
<<
<< Documentation Display
<<
<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
<<
<<
<<
<<Important Dates
<<
<< March 1, 1990 Presentation proposals due
<< April 1, 1990 Notification of proposal acceptance
<< May 1, 1990 Final Papers due
<< June 1, 1990 Newsletter entries due
<< June 1, 1990 Technical writing entries due
<< June 15, 1990 Notification of paper/panel acceptance
<< September 1, 1990 Deadline for materials for
<< documentation display
<<
<<
<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
<<
<<Presentation Topic Areas
<<
<<
<<Information Exchange Technology
<<
<<Information exchange may well be the most important computing
<<activity of the 1990s. The infrastructure for information delivery, the
<<National Research and Academic Network (NREN), is presently being developed.
<<How do we meet the challenges of a world where the
<<facilitation of information delivery may be a principal user services
<<responsibility? Topics of particular interest include:
<<
<< new approaches to information exchange
<<
<< campus activity in implementing information exchange
<< facilities that comply with emerging international standards
<<
<< research and development of computer-mediated information
<< exchange methods
<<
<<
<<Distributed Services
<<
<<As the role of user services shifts to providing distributed support,
<<we must create new ways of providing traditional services as well as
<<designing new services. Topics of particular interest include:
<<
<< providing support staff in departments and colleges
<<
<< funding issues
<<
<< if and how to charge back for services
<<
<< human networking of distributed support staff
<<
<< nonlabor-intensive support strategies
<<
<< cooperative efforts with other departments
<<
<<
<<
<<Management Strategies
<<
<<How do user services managers cooperate with other administrative and
<<academic units that use or provide computing resources? How do they
<<meet the many and diverse demands? Topics of particular interest include:
<<
<< reorganization
<<
<< interaction with faculty advisory groups
<<
<< delegating and distributing responsibility
<<
<< coordinating university computing resources
<<
<< staff professional development
<<
<<
<<Marketing your Services
<<
<<Changing roles may require changing your services and, often, your image on
<<campus as you provide new services to new users. Topics of particular in-
<<terest include:
<<
<< promotional strategies
<<
<< conducting market research
<<
<< designing services for unique or special audiences
<<
<<
<<
<<Strategies for Small Schools
<<
<<How can a small liberal arts college have distributed user services and
<<centralized user services? How do distributed and centralized services work
<<together to provide computing services beyond word processing? The
<<sciences have become computer literate; now, how do we reach out from the
<<center to the humanities and fine arts? Are we getting out of the
<<office and into the trenches? Are we making too many "house calls"?
<<Should we make them at all?
<<
<<
<<Security and Ethics
<<
<<As electronic mail and conferencing become more popular, computing
<<systems are widely accessible to more users. How secure should academic
<<computing resources be? What are the ethical guidelines provided for users
<<of electronic mail and conferencing systems? Topics of particular interest
<<include:
<<
<< promoting responsible and ethical use of computing resources
<<
<< security strategies
<<
<< adopting an ethics policy
<<
<<
<<Serving New Audiences
<<
<<People from the humanities, the arts, and other traditionally nontechnical
<<disciplines are discovering that computers can help in areas other than
<<word processing. In an increasingly proactive stance in the central
<<computing facility, what do we do to attract and support these new audi-
<<ences? Topics of interest include:
<<
<< providing information about off-the-shelf specialized
<< programs for music, fine arts, and the humanities
<<
<< facilitating technical support of nontraditional areas
<<
<< serving the computing beginner who wants to do
<< sophisticated tasks
<<
<<
<<Consulting, Training, and Documentation
<<
<<Supporting those who use the computing resources that we provide re-
<<mains an important responsibility of user services organizations. Topics
<<of particular interest include:
<<
<< new approaches to training
<<
<< providing distributed consulting
<<
<< documentation distribution services
<<
<<
<<and/or other topics that would be of interest to your national
<<and international colleagues
<<
<<
<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
<<
<<Submitting Proposals
<<
<<
<<Submit proposals via electronic mail to:
<<
<< SIGPAPER@OHSTVMA.BITNET or
<<
<< SIGPAPER@OHSTVMA.IRCC.OHIO-STATE.EDU
<<
<<If you do not have access to electronic mail, send a printed copy to:
<<
<< Susan Jenkins Saari
<< Instruction and Research
<< Computer Center
<< The Ohio State University
<< 1971 Neil Avenue
<< Columbus, OH 43210
<<
<< phone: (614) 292-4843
<< fax: (614) 292-7081
<<
<<
<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
<<
<<Accepted Proposals
<<
<<
<<Proposals must be received by March 1, 1990. Any submisson received
<<after this date will not be considered by the Program Committee. You will
<<be notified of the Program CommitteeUs decision by April 1, 1990. If your
<<proposal is accepted, you will be asked to submit a full paper by May 1,
<<1990. Any papers received after this date will not be considered. You will
<<be notified of the Program CommitteeUs decision by June 15, 1990.
<<
<<If your presentation is accepted, SIGUCCS is depending on you. If you are
<<ker to make your presentation (not a substitute presentation).
<<
<<
<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
<<
<<
<<How to Participate
<<
<<
<<Proposals
<<
<<For each proposal, include your name, title, affiliation, mailing ad-
<<type of proposal (presentation or panel discussion) and its topic area.
<<In addition, you must enclose the proper materials from the following
<<requirements list:
<<
<<Description
<<
<<Papers Papers will be presented in 20-minute ntervals, with
<< three papers scheduled per 90-minute session. Speakers'
<< papers will be published in the conference proceedings.
<<
<<Panels Panels will be in-depth treatments of a single topic by
<< two to four speakers from at least two different schools,
<< coordinated by a moderator. Allow ample time for audience
<< discussion. Abstracts for panels should be submitted
<< as a unit by the person who wishes to act as a moderator.
<< Panelists' papers will be published in the conference
<< proceedings.
<<
<<Quick Workshops Quick workshops provide 90-minute overviews of new technolo-
<< gies, innovative applications, and creative strategies
<< for addressing the needs of computer users on campus.
<<
<<
<<Requirements
<<
<<Papers A 250- to 300-word abstract of the paper. Acceptance of
<< a proposal does not automatically ensure acceptance
<< of a paper for presentation; you must submit a full
<< paper to be considered for the conference program.
<<
<<Panels A 250- to 300-word description of the panel, including
<< each panelist's name, title, affiliation, and presentation
<< topic. Acceptance of a panel description does not
<< automatically ensure acceptance of the panel for
<< presentation; each panelist must submit a full paper
<< to be considered for the conference program.
<<
<<Quick Workshops A one- to two-page outline of the presentation and a
<< 10-minute videotape excerpt from the proposed presentation.
<< Acceptance of a proposal does not automatically ensure
<< acceptance of a workshop for presentation; you must
<< submit a full paper to be considered for the conference
<< program. Only three or four presentations will be a
<< ccepted in this category because it is highly competiive.
<<
<<
<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
<<
<<
<<Other Ways to Participate
<<
<<Education and Training Materials Competition
<<
<<Interest in and the importance of user education and training have grown
<<with each SIGUCCS conference. The 1990 SIGUCCS Conference offers,
<<for the first time, competition for user education and training materials for
<<colleges and universities.* We invite you to submit no more than two
<<entries in any or all of the following categories: curriculum catalog, class-
<<room printed materials, or self-contained printed tutorials. Although the
<<first year of this competition includes only printed materials, we would like
<<to know if there is an interest in expanding our future competitions to
<<include video, audio, and computer-based tutorials. Deadline for entry is
<<June 1, 1990. For more details and an entry form, or to address the issue
<<of future competition categories, contact:
<<
<< Diane Jung-Gribble
<< Indiana University
<< 750 North State Road 46 Bypass
<< Bloomington, IN 47405
<<
<< (812) 855-0962
<<
<<
<< JUNG@IUBACS.BITNET
<< JUNG@JADE.BACS.INDIANA.EDU
<<
<<*NOTE: this competition is not open to commercial materials
<<
<<Newsletter Competition
<<
<<Winning an award in the SIGUCCS Newsletter Competition is a mark of
<<distinction for your institution, and for your editors, writers,artists,and
<<designers. You will be asked to submit two consecutive issues published
<<between June 1989 and May 1990. Deadline for entry is June 1, 1990.
<<For more details and an entry form, contact:
<<
<< Jess Anderson
<< Madison Academic Computing Center
<< University of Wisconsin-Madison
<< 1210 West Dayton Street
<< Madison, WI 53706
<<
<< (608) 263-6988
<<
<< ANDERSON@MACC.WISC.EDU
<< ANDERSON@WISCMACC.BITNET
<<
<<
<<Technical Writing Competition
<<
<<If you have written or published a particularly good article in a computing
<<newsletter, enter it in the Technical Writing Competition. Each computing
<<center may enter one article. Deadline for entry is June 1,1990. To obtain
<<entry forms and more details, contact:
<<
<< Donald J. Montabana
<< University of Pennsylvania
<< Computing Resources Center
<< 1202 Blockley Hall
<< Philadelphia, PA 19104-6021
<<
<< (215) 898-9085
<<
<< MONTABANA@A1.RELAY.UPENN.EDU
<<
<<
<<
<<Documentation Display
<<
<<The documentation room will feature an online system for submitted
<<documentation. Conference attendees who have BITNET or INTERNET
<<access will be able to email documentation to their university or college.
<<Documentation may be submitted electronically to DOCUMENT@MIAMIU,
<<by hardcopy, or diskette (IBM or Mac formatted) and must be received
<<before September 1, 1990. Direct inquries to:
<<
<< Al Kaled
<< Academic Computing Services
<< Miami University
<< Oxford, OH 45056
<<
<< (513) 529-6226
<<
<< AK75STAF@MIAMIU
<<
<<
<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
<<
<<
<<More Information
<<
<<
<<General Information
<
<<Amin Shafie, Conference Chair
<<University of Cincinnati
<<
<<
<< e-mail: SHAFIE@UCBEH.BITNET
<<
<< phone: (513) 556-9001
<<
<< fax: (513) 556-0035
<<
<<
<<Call for Participation
<<Susan Jenkins Saari, Program Chair
<<The Ohio State University
<<
<< e-mail: SIGPAPER@OHSTVMA.BITNET
<<
<< phone: (614) 292-4843
<<
<< fax: (614) 292-7081
<<
<<
<<Registration
<<Ken Maccarone, Registration Chair
<<University of Cincinnati
<<
<< e-mail: MACCARON@UCBEH.BITNET
<<
<<
<< phone: (513) 556-9098
<< fax: (513) 556-0035
<<
<<
<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
<<
<<
<<ACM SIGUCCS
<<
<<The Association of Computing Machinery's (ACM) Special Interest Group
<<for University and College Computing (SIGUCCS) is one of ACM's
<<organizational units devoted to the technical activities of its members.
<<SIGUCCS provides a link for guidance and the interchange of ideas among
<<computing professionals in the full range of small to large institutions.
<<Its newsletter, annual conferences, and workshops promote the discussion
<<of mutual problems. networks, user services, and computer center management.
<<This SIGUCCS conference emphasizes practical ways to improve services for
<<those who use university and college computing centers.
Amin Shafie
Assistant Director
Academic Computing Services UCBEH::SHAFIE
University of Cincinnati SHAFIE@UCBEH.SAN.UC.EDU
ML 088 SHAFIE@UCBEH.BITNET
Cincinnati, Ohio 45221
(513) 556-9022
------------------------------
End of Scheme Digest
********************
∂12-Jan-90 2253 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #273
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 12 Jan 90 22:53:05 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA14728; Sat, 13 Jan 90 01:53:03 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Sat, 13 Jan 90 01:52:22 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa09252;
13 Jan 90 0:29 EST
Date: 13 JAN 90 00:02:03 EST
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.lcs.mit.edu>
Subject: Scheme Digest #273
To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Message-Id: <9001130029.aa09252@mintaka.lcs.mit.edu>
Scheme Digest #273 13 JAN 90 00:02:03 EST
Today's Topics:
Compiling Scheme
Compiling Scheme (Summary)
HELP
----------------------------------------------------------------------
Date: 12 Jan 90 03:58:58 GMT
From: Ken Dickey <zephyr.ens.tek.com!tekcrl!tekchips!kend@beaver.cs.washington.edu>
Subject: Re: Compiling Scheme
Message-Id: <5375@tekcrl.LABS.TEK.COM>
Upon reading my posting I see that I forgot Kent Dybvig's Thesis:
"Three Implementation Models for Scheme",
U of North Carolina at Chappel Hill, 1987.
(Sorry, Kent!)
-Ken Dickey
------------------------------
Date: 12 Jan 90 22:48:39 GMT
From: Dirk Grunwald <grunwald@boulder.colorado.edu>
Subject: Re: Compiling Scheme (Summary)
Message-Id: <15594@boulder.Colorado.EDU>
sadly, you all missed one of the more interesting papers, by luddy
harrison at the Univ. of Illinois Center for Supercomputing Res. and
Dev. (CSRD).
``compiling lisp for evaluation on a tightly coupled multiprocessor''
CSRD tech report #565 by W. Ludwell Harrison, III
luddy wrote a scheme compiler that allegedly out-gabriales everything.
It runs on an alliant FX-8. It concurrentizes & vectorizes, if I
recall correctly.
Dirk Grunwald -- Univ. of Colorado at Boulder (grunwald@foobar.colorado.edu)
(grunwald@boulder.colorado.edu)
------------------------------
Date: 12 Jan 90 07:47 PST
From: Peter Schindler <schindler@vax1.informatik.fh-regensburg.dbp.de>
Message-ID: <4:schindler@vax1.informatik.fh-regensburg.dbp.de>
Subject: HELP
HELP
------------------------------
End of Scheme Digest
********************
∂14-Jan-90 0744 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #274
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 14 Jan 90 07:44:43 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA05627; Sun, 14 Jan 90 05:02:31 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Sun, 14 Jan 90 05:01:54 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa23204;
14 Jan 90 0:16 EST
Date: 14 JAN 90 00:02:05 EST
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.lcs.mit.edu>
Subject: Scheme Digest #274
To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Message-Id: <9001140016.aa23204@mintaka.lcs.mit.edu>
Scheme Digest #274 14 JAN 90 00:02:05 EST
Today's Topics:
location of SIOD
Revised↑4 Definition
----------------------------------------------------------------------
Message-Id: <9001131533.AA20984@bu-it.bu.edu>
Date: Sat, 13 Jan 90 10:34 EST
From: GJC@buenga.bu.edu
Subject: location of SIOD
Clarification of the location of SIOD: Scheme in One Defun.
BU.EDU is 128.197.2.6, users/gjc/siod-v2.3-shar
------------------------------
Date: 13 Jan 90 20:02:34 GMT
From: Jason Coughlin <samsung!brutus.cs.uiuc.edu!rpi!image.soe.clarkson.edu!jk0@think.com>
Subject: Revised↑4 Definition
Message-Id: <1990Jan13.200234.18252@sun.soe.clarkson.edu>
Have I heard correctly that there is now a Revised↑4 Report on
Scheme? If so, where can I get the LaTeX source for it?
--
Jason Coughlin ( jk0@sun.soe.clarkson.edu , jk0@clutx )
"Every jumbled pile of person has a thinking part that wonders what the
part that isn't thinking isn't thinking of." - They Might Be Giants
------------------------------
End of Scheme Digest
********************
∂15-Jan-90 2231 Scheme-REQUEST@mc.lcs.mit.edu Scheme Digest #275
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 15 Jan 90 22:31:32 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA27321; Tue, 16 Jan 90 01:30:33 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Tue, 16 Jan 90 01:29:52 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa05366;
16 Jan 90 0:41 EST
Date: 16 JAN 90 00:02:17 EST
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.lcs.mit.edu>
Subject: Scheme Digest #275
To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
Message-Id: <9001160041.aa05366@mintaka.lcs.mit.edu>
Scheme Digest #275 16 JAN 90 00:02:17 EST
Today's Topics:
----------------------------------------------------------------------
From: attmail!uucp@att.att.com
Date: Sun Jan 14 14:39:56 EST 1990
Message-ID: <9001151607.aa22174@mintaka.lcs.mit.edu>
Received: from attbl by attmail; Sun Jan 14 19:39 GMT 1990
>From arpa!CUNYVM.CUNY.EDU!Scheme%mc.lcs.mit.edu%mintaka.lcs.mit.edu Sun Jan 14 00:02:05 EST 1990 remote from attbl
Received: from SCF.FUNDP.AC.BE by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 7238; Sun, 14 Jan 90 05:17:49 EDT
Received: by BNANDP11 (Mailer R2.02A) id 4771; Sun, 14 Jan 90 11:17:27 +0100
Date: Sun, 14 Jan 90 00:02:05 EST
Reply-To: Scheme%mc.lcs.mit.edu%mintaka.lcs.mit.edu@CUNYVM.CUNY.EDU
Sender: Scheme Programming Language <SCHEME%BNANDP11.BITNET@CUNYVM.CUNY.EDU>
From: attbl!arpa!CUNYVM.CUNY.EDU!Scheme%mc.lcs.mit.edu%mintaka.lcs.mit.edu (Automatic Scheme Digestifier)
<Scheme-Request%mc.lcs.mit.edu@MINTAKA.LCS.MIT.EDU>
Subject: Scheme Digest #274
Comments: To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
To: ICSUG TEST GROUP
<attmail!mhs!envoy!ICS.TEST/PN=_TEST_GROUP@ATT.ATT.COM>
Scheme Digest #274 14 JAN 90 00:02:05 EST
Today's Topics:
location of SIOD
Revised↑4 Definition
----------------------------------------------------------------------
Message-Id: <9001131533.AA20984@bu-it.bu.edu>
Date: Sat, 13 Jan 90 10:34 EST
From: GJC@buenga.bu.edu
Subject: location of SIOD
Clarification of the location of SIOD: Scheme in One Defun.
BU.EDU is 128.197.2.6, users/gjc/siod-v2.3-shar
------------------------------
Date: 13 Jan 90 20:02:34 GMT
From: Jason Coughlin
<samsung!brutus.cs.uiuc.edu!rpi!image.soe.clarkson.edu!jk0@think.com>
Subject: Revised↑4 Definition
Message-Id: <1990Jan13.200234.18252@sun.soe.clarkson.edu>
Have I heard correctly that there is now a Revised↑4 Report on
Scheme? If so, where can I get the LaTeX source for it?
--
Jason Coughlin ( jk0@sun.soe.clarkson.edu , jk0@clutx )
"Every jumbled pile of person has a thinking part that wonders what the
part that isn't thinking isn't thinking of." - They Might Be Giants
------------------------------
End of Scheme Digest
********************
------------------------------
End of Scheme Digest
********************
∂16-Jan-90 2339 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #276
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 16 Jan 90 23:39:35 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA09119; Wed, 17 Jan 90 02:39:22 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Wed, 17 Jan 90 02:38:37 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa05215;
17 Jan 90 2:33 EST
Message-Id: <DIGEST.183.900117.023234.6@MC.LCS.MIT.EDU>
Date: 17 Jan 90 02:32:34 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #276
Scheme Digest #276 17 Jan 90 02:32:34 EST
Today's Topics:
(none)
() as an expression (3 messages)
Administrivia:
The Scheme Digest is now being produced by a new automatic digestifier. If
you notice any problems caused by this change, please report them to us.
(Note that this change is unrelated to the recent problems where an errant
mailer is sending entire digests back to us as submissions.)
Scheme-Request@LCS.MIT.EDU
----------------------------------------------------------------------
Message-ID: <502@qusunitb.queensu.CA>
Date: 15 Jan 90 16:11:36 GMT
From: Prakash Panangaden <cs.utexas.edu!jarvis.csri.toronto.edu!qucis!prakash@yale-zoo.arpa>
To: scheme@mc.lcs.mit.edu
Subject: Re: (none)
Is there anyone who knows where to get PC schemes in Canada?
Thanks
------------------------------
Message-ID: <1990Jan16.193134.10491@sun.soe.clarkson.edu>
Date: 16 Jan 90 19:31:34 GMT
From: Jason Coughlin <image.soe.clarkson.edu!jk0@uunet.uu.net>
To: scheme@mc.lcs.mit.edu
Subject: () as an expression
The Revised↑3 Report says that () is an illegal expression. It must
be quoted. However, MIT-Scheme and PC-Scheme both allow it, ie:
MIT-SCHEME => ()
()
MIT-SCHEME =>
Why is () an invalid expression? It seems to me that it is a constant.
(eq? #t #t) => #t
(eq? #f #f) => #t
(eq? '() '()) => #t
now why isn't () considered a constant, when it really IS a constant?
--
Jason Coughlin ( jk0@sun.soe.clarkson.edu , jk0@clutx )
"Every jumbled pile of person has a thinking part that wonders what the
part that isn't thinking isn't thinking of." - They Might Be Giants
------------------------------
Message-ID: <5413@tekcrl.LABS.TEK.COM>
Date: 16 Jan 90 20:55:13 GMT
From: Ken Dickey <zephyr.ens.tek.com!tekcrl!tekchips!kend@uunet.uu.net>
To: scheme@MC.lcs.mit.edu
Subject: Re: () as an expression
In article <1990Jan16.193134.10491@sun.soe.clarkson.edu> jk0@sun.soe.clarkson.edu (Jason Coughlin) writes:
>The Revised↑3 Report says that () is an illegal expression. It must
>be quoted. However, MIT-Scheme and PC-Scheme both allow it, ie:
..
>Why is () an invalid expression? It seems to me that it is a constant.
>
>(eq? #t #t) => #t
>(eq? #f #f) => #t
>(eq? '() '()) => #t
>
>now why isn't () considered a constant, when it really IS a constant?
The syntax () is considered a combination (a.k.a. procedure call) and
as such must have at lease one subexpression. So, the empty list is
valid, but the empty combination is an error.
Note also that #f and '() may be distinct in newer Scheme
implementations [the value of (eq? '() #f) is currently unspecified].
There are other non-R↑3RS behaviors allowed by various versions of
Scheme implementations, particularly those implementations done before
R↑3RS was issued.
-Ken Dickey
------------------------------
Message-ID: <1990Jan16.231311.18316@sun.soe.clarkson.edu>
Date: 16 Jan 90 23:13:11 GMT
From: Jason Coughlin <snorkelwacker!usc!zaphod.mps.ohio-state.edu!rpi!image.soe.clarkson.edu!jk0@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: () as an expression
From article <5413@tekcrl.LABS.TEK.COM>, by kend@tekchips.LABS.TEK.COM (Ken Dickey):
> Note also that #f and '() may be distinct in newer Scheme
> implementations [the value of (eq? '() #f) is currently unspecified].
This leads to another point: I think we need a definitive answer on
whether #f == (). In my Scheme, #f and () are two different entities.
I like this because in my mind, #f != (). #f is boolean, () is an empty
list.
So what say you about:
(BOOLEAN? '())
(NULL? '())
(EQ? '() #f)
--
Jason Coughlin ( jk0@sun.soe.clarkson.edu , jk0@clutx )
"Every jumbled pile of person has a thinking part that wonders what the
part that isn't thinking isn't thinking of." - They Might Be Giants
------------------------------
End of Scheme Digest
********************
∂17-Jan-90 2343 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #277
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 17 Jan 90 23:43:52 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA28948; Thu, 18 Jan 90 02:42:14 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Thu, 18 Jan 90 02:41:50 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa28775;
18 Jan 90 2:32 EST
Message-Id: <DIGEST.183.900118.023303.8@MC.LCS.MIT.EDU>
Date: 18 Jan 90 02:33:02 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #277
Scheme Digest #277 18 Jan 90 02:33:02 EST
Today's Topics:
Another compiling Scheme reference
----------------------------------------------------------------------
Message-ID: <9001130114.AA17216@jove.pa.dec.com>
Date: Fri, 12 Jan 90 17:14:30 PST
From: bartlett@decwrl.dec.com
To: Scheme%mc.lcs.mit.edu@MINTAKA.lcs.mit.edu
CC: bartlett@lcs.mit.edu
Subject: Another compiling Scheme reference
Joel F. Bartlett, Scheme->C a Portable Scheme-to-C Compiler, WRL Research
Report 89/1, Digital Equipment Corporation Western Research Laboratory,
January 1989.
------------------------------
End of Scheme Digest
********************
∂22-Jan-90 0930 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #278
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Jan 90 09:29:46 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA23062; Mon, 22 Jan 90 12:26:44 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Mon, 22 Jan 90 03:30:57 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa23297;
22 Jan 90 3:05 EST
Message-Id: <DIGEST.183.900122.023751.22@MC.LCS.MIT.EDU>
Date: 22 Jan 90 02:37:51 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #278
Scheme Digest #278 22 Jan 90 02:37:51 EST
Today's Topics:
scheme manual
----------------------------------------------------------------------
Message-ID: <9001211521.AA29490@cmvax.nrl.navy.mil>
Date: Sun, 21 Jan 90 10:21:58 EST
From: Eric Hoffman <hoffman@cmvax.nrl.navy.mil>
To: scheme@ai.mit.edu
Subject: scheme manual
Is there a manual which deals with scheme contructs
and concepts availiable through a publisher or
over the network, aside from the release notes?
-Eric Hoffman
Connection Machine Facility
Naval Research Laboratory
------------------------------
End of Scheme Digest
********************
∂23-Jan-90 0538 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #279
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Jan 90 05:38:06 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA08259; Tue, 23 Jan 90 05:09:10 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Tue, 23 Jan 90 05:08:44 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa10049;
23 Jan 90 2:43 EST
Message-Id: <DIGEST.183.900123.020813.26@MC.LCS.MIT.EDU>
Date: 23 Jan 90 02:08:12 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #279
Scheme Digest #279 23 Jan 90 02:08:12 EST
Today's Topics:
Multiple copies of Digest #276
(none)
1 message without subject
----------------------------------------------------------------------
Message-ID: <9001221019.aa05664@mintaka.lcs.mit.edu>
Date: Mon, 22 Jan 90 10:11 EST
From: JJLACEY%OWUCOMCN.BITNET@mitvma.mit.edu
To: scheme@lcs.mit.edu
Subject: Multiple copies of Digest #276
To date (22 Jan 1990, 10:00am), I have received 3 copies of this beast.
Now, mind you, I *like* these digests, but I feel that this is a problem,
and not a treat.
Thanks for your consideration.
John Lacey
jjlacey@owucomcn.bitnet
------------------------------
Message-ID: <3055@odin.SGI.COM>
Date: 22 Jan 90 16:06:43 GMT
From: Jonathan Shapiro <sgi!shinobu!odin!delrey!shap@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: (none)
Can we arrange for archives to get a proper subject line? It's pretty
irritating to see identical content in the digest and the newsgroup,
and I would like to be able to kill one or the other in my kill file.
Killing all things from postmaster@att... doesn't seem like the ideal
solution.
Jon Shapiro
------------------------------
Message-ID: <9001222139.aa00684@mintaka.lcs.mit.edu>
Date: Mon, 22 Jan 90 21:24:32 EST
From: postmaster@att-in.att.com
To: Scheme%lcs.mit.edu@cunyvm.cuny.edu
Mail to `att.att.com!attmail!mhs!envoy!ics.test/pn=_test_group' alias `att!attmail!mhs!envoy!ics.test/pn=_test_group' from 'CUNYVM.CUNY.EDU!Scheme%lcs.mit.edu' failed.
The error message was:
destination unknown or forwarding disallowed
The message began:
Received: from SCF.FUNDP.AC.BE by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 2397; Mon, 22 Jan 90 21:25:13 EST
Received: by BNANDP11 (Mailer R2.02A) id 4855; Tue, 23 Jan 90 03:25:07 +0100
Date: Mon, 22 Jan 90 02:37:51 EST
Reply-To: Scheme%lcs.mit.edu@CUNYVM.CUNY.EDU
Sender: Scheme Programming Language <SCHEME%BNANDP11.BITNET@CUNYVM.CUNY.EDU>
From: Automatic Scheme Digestifier <Scheme-Request%LCS.MIT.EDU@CUNYVM.CUNY.EDU>
Subject: Scheme Digest #278
Comments: To: Scheme@lcs.mit.edu
To: ICSUG TEST GROUP
<attmail!mhs!envoy!ICS.TEST/PN=_TEST_GROUP@ATT.ATT.COM>
Scheme Digest #278 22 Jan 90 02:37:51 EST
Today's Topics:
scheme manual
---------------------------------------------------------------------
Message-ID: <9001211521.AA29490@cmvax.nrl.navy.mil>
Date: Sun, 21 Jan 90 10:21:58 EST
From: Eric Hoffman <hoffman@cmvax.nrl.navy.mil>
To: scheme@ai.mit.edu
Subject: scheme manual
Is there a manual which deals with scheme contructs
and concepts availiable through a publisher or
over the network, aside from the release notes?
-Eric Hoffman
Connection Machine Facility
Naval Research Laboratory
-----------------------------
End of Scheme Digest
********************
------------------------------
End of Scheme Digest
********************
∂24-Jan-90 1638 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #280
Received: from life.ai.mit.edu ([128.52.32.80]) by SAIL.Stanford.EDU with TCP; 24 Jan 90 16:37:49 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA27829; Wed, 24 Jan 90 03:15:32 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Wed, 24 Jan 90 03:15:00 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa06345;
24 Jan 90 2:56 EST
Message-Id: <DIGEST.184.900124.021506.32@MC.LCS.MIT.EDU>
Date: 24 Jan 90 02:15:06 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #280
Scheme Digest #280 24 Jan 90 02:15:06 EST
Today's Topics:
() as an expression
----------------------------------------------------------------------
Message-ID: <1990Jan23.203035.148@vicom.com>
Date: 23 Jan 90 20:30:35 GMT
From: Roderic Taylor <snorkelwacker!apple!vsi1!roderic@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: () as an expression
In a recent article Jason Coughlin (jk0@sun.soe.clarkson.edu) writes:
=
=Why is () an invalid expression? It seems to me that it is a constant.
=
() is not a constant. '() is a constant (at least in the sense
you're thinking). This is the way Lisp works with all lists, not
just the empty one.
--Roderic T
------------------------------
End of Scheme Digest
********************
∂25-Jan-90 0037 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #281
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 25 Jan 90 00:37:50 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA17941; Thu, 25 Jan 90 03:36:35 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Thu, 25 Jan 90 03:36:08 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa04437;
25 Jan 90 3:17 EST
Message-Id: <DIGEST.184.900125.023855.38@MC.LCS.MIT.EDU>
Date: 25 Jan 90 02:38:55 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #281
Scheme Digest #281 25 Jan 90 02:38:55 EST
Today's Topics:
() as an expression
----------------------------------------------------------------------
Message-ID: <9001241620.AA04533@ungar.think.com>
Date: Wed, 24 Jan 90 11:20:48 EST
From: Guy Steele <gls@think.com>
To: Scheme@lcs.mit.edu
CC: gls@think.com
Subject: () as an expression
Message-ID: <1990Jan23.203035.148@vicom.com>
Date: 23 Jan 90 20:30:35 GMT
>From: Roderic Taylor <snorkelwacker!apple!vsi1!roderic@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
In a recent article Jason Coughlin (jk0@sun.soe.clarkson.edu) writes:
Why is () an invalid expression? It seems to me that it is a constant.
() is not a constant. '() is a constant (at least in the sense
you're thinking). This is the way Lisp works with all lists, not
just the empty one.
Begging your pardon, but this is the way *Scheme* works with all lists.
As dearly as we may love Scheme, we must recognize that there are
other dialects of Lisp, some of greater seniority.
--Guy
------------------------------
End of Scheme Digest
********************
∂26-Jan-90 0017 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #282
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 26 Jan 90 00:17:47 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA06630; Fri, 26 Jan 90 03:11:47 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Fri, 26 Jan 90 03:11:15 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa27395;
26 Jan 90 2:57 EST
Message-Id: <DIGEST.184.900126.024230.2@MC.LCS.MIT.EDU>
Date: 26 Jan 90 02:42:30 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #282
Scheme Digest #282 26 Jan 90 02:42:30 EST
Today's Topics:
Scheme as a standard extension language
----------------------------------------------------------------------
Message-ID: <1486@viewlog.UUCP>
Date: 24 Jan 90 23:13:30 GMT
From: Josh Marantz <zaphod.mps.ohio-state.edu!usc!apple!netcom!stratus!cloud9!viewlog!josh@think.com>
To: scheme@mc.lcs.mit.edu
Subject: Scheme as a standard extension language
I'm on a subcommittee of the CAD Framework Initiative (CFI), and we're
working to standardize on a specific standard extension language for
Electrical CAD/CAE applications.
The mission of CFI is "To develop world-wide industry acceptable
guidelines for design automation frameworks which will enable the
coexistence and cooperation of a variety of tools."
The goal of the working group on extension languages is to provide
integrators and users of multi-vendor systems a single extension
language that will work with all their applications.
The obvious analogy is that different flavors of Emacs have compatible
user interfaces and philosophies, but totally incompatible extension
languages (EEL, Mocklisp, Elisp, Teco...). Wouldn't it be nice if
they standardized?
Whether or not you agree with this premise, we are trying to come up
with a standard language (for some definition of "standard") that meets
various criteria. The criteria include:
High Productivity (implies high level language)
Good development environment
Automatic memory management (garbage collection)
Specific runtime call to reclaim memory (collect garbage)
Easy construction of complex data structures
Easy manipulation of strings, lists, and complex data structures
Quick turn around of code changes
Rapid prototyping
Built in debugging capability
Public domain source and commercial products available
Easy to parse EDIF using extension language
Late binding
Dynamic binding
Able to express rules and constraints
Able to construct module generator (to generate cells)
Sequential model of execution (stream i/o)
Standard language with a large user base
Multiple namespaces (packages)
Access to all other parts of framework from extension language
We could try to invent our own language that meets these requirements, but
leveraging off an existing standard is a high priority for us.
The two languages that we've come up with that come closest to meeting
these requirements are Common Lisp and Scheme. Common Lisp is
feature-rich and requires the fewest extensions to provide the
features we need. But it is huge and thereby dictates certain
architectural considerations and platform requirements where it would
be nice to remain more flexible. In particular, it may be desirable
to have several applications running on a workstation, each of which
has its own extension language processor linked in. Correct me if I'm
wrong, but if the extension language is 2 Meg worth of Common Lisp,
then this would not be a design option. My understanding is that
shared libraries might ease the problem, but would not eliminate it.
However, standard Common Lisp (with CLOS and the Pittman error
handler) provide us a nearly complete package that we wouldn't have to
augment. The useful features it provides that Scheme doesn't include:
structure definition (defstruct), error handling, an object/class
system, hash tables, optional strong typing, looping constructs, and
efficient compilation.
Scheme is more elegant and streamlined, but would require a large
number of extensions to supply all the features we need. I couldn't
find many of the required features in R3RS, but I've seen them in
various implementations of Scheme. For example:
Packages MIT-Scheme
Debugging Support MIT-Scheme
Object Oriented Programming XScheme
Simple integration with C Code SIOD
I personally support Scheme as the basis for an extension language,
primarily because it can be implemented without a big memory hit (as was
done with SIOD). It seems to me that even with the extensions we need,
Scheme would still be leaner than Common Lisp. For example, packages and
an object/class system can be trivially implemented with environments.
But what I need to present my case better is some sort of "common"
extension package that can provide the features we require. Is there
an effort out there to define extensions and enhancements that I could
present along with R3RS to the committee? Or should I try to come up
with a "Scheme's greatest hits" collection and suggest that we
standardize on those extensions as well as R3RS?
Any comments from the Scheme and Lisp communities are welcome. If
Common Lisp is not as expensive as I assume, then I'm sure someone
will correct me!
--
Joshua Marantz
Viewlogic Systems, Inc.
cloud9!viewlog!josh@bu-cs.bu.edu
------------------------------
End of Scheme Digest
********************
∂27-Jan-90 0011 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #283
Received: from life.ai.mit.edu ([128.52.32.80]) by SAIL.Stanford.EDU with TCP; 27 Jan 90 00:11:44 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA22981; Sat, 27 Jan 90 03:06:38 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Sat, 27 Jan 90 03:06:08 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa13286;
27 Jan 90 2:50 EST
Message-Id: <DIGEST.184.900127.022732.8@MC.LCS.MIT.EDU>
Date: 27 Jan 90 02:27:32 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #283
Scheme Digest #283 27 Jan 90 02:27:32 EST
Today's Topics:
Scheme and CAD
Scheme as a standard extension language
----------------------------------------------------------------------
Message-ID: <9001261301.AA23617@bronto.soar.cs.cmu.edu>
Date: Fri, 26 Jan 90 08:01:21 EST
From: Olin Shivers <shivers@bronto.soar.cs.cmu.edu>
To: cloud9!viewlog!josh@cs.bu.edu
CC: Scheme@MINTAKA.LCS.MIT.EDU
Subject: Scheme and CAD
You are missing one or two good bets.
Joel Bartlett at DECWRL has done an implementation of R3RS that compiles to C
called Scheme->C. There is a paper on this implementation available from
WRL. Scheme->C was designed with an eye to using it as an embedded command
processor, writing standalone executables, and linking Scheme code together
with C code, so it sounds like just the thing for what you have in mind.
You can get Bartlett's paper from the slick WRL mail server. To find out
how, send a message with subject line "help" to
wrl-techreports@decwrl.dec.com or
{someplace}!decwrl!wrl-techreports
T has a very nice packages system, called locales, an object-oriented
extension, which is directly supported by the native-code optimizing compiler.
Calling C from T is not too hard; calling T from C is hard.
You can get T for most 68K, Vax, R2000, and Sparc systems -- it can be
ftp'd from MIT. If you want to know more, contact kranz@wheaties.ai.mit.edu.
-Olin
------------------------------
Message-ID: <9001260953.AA29337@tub.UUCP>
Date: Fri, 26 Jan 90 10:53:00 +0100
From: Oliver Laumann <net%TUB.BITNET@mitvma.mit.edu>
To: Scheme@lcs.mit.edu
CC: josh@think.com
Subject: Re: Scheme as a standard extension language
If you are interested in using Scheme as a standard extension language,
you might want to look into the recently posted implementation of
Scheme named `Elk' (Extension Language Kit).
One purpose of the Elk project was to end the recent proliferation
of (often mutually incompatible) Lisp-like extension languages.
Instead of inventing and implementing yet another extension language,
we expect application programmers to link the Scheme interpreter into
their application in order to make it extensible and customizable.
We feel that Scheme is better suited as a general extension language
than other Lisp dialects: it is sufficiently small to not dwarf the
application it serves and to be fully understood with acceptable
effort; it is orthogonal and well-defined. In addition, Scheme has
been recognized to be mature enough for national and international
standardization (IEEE P1178, ISO/IEC JTC1/SC22/WG16).
The `Elk' Scheme interpreter can easily be extended by application-specific
new data types and primitive procedures. Such extensions are typically
written in C or C++ and dynamically loaded into the running interpreter.
Regards,
--
Oliver Laumann net@TUB.BITNET net@tub.UUCP
------------------------------
End of Scheme Digest
********************
∂27-Jan-90 2328 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #284
Received: from life.ai.mit.edu ([128.52.32.80]) by SAIL.Stanford.EDU with TCP; 27 Jan 90 23:28:08 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA02910; Sun, 28 Jan 90 02:24:22 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Sun, 28 Jan 90 02:23:55 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa20577;
28 Jan 90 2:11 EST
Message-Id: <DIGEST.184.900128.021234.12@MC.LCS.MIT.EDU>
Date: 28 Jan 90 02:12:33 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #284
Scheme Digest #284 28 Jan 90 02:12:33 EST
Today's Topics:
Scheme as a standard extension language
Combinators & Compilation
----------------------------------------------------------------------
Message-ID: <1990Jan27.222837.3997@odi.com>
Date: 27 Jan 90 22:28:37 GMT
From: Dan Weinreb <odi!dlw@uunet.uu.net>
To: scheme@mc.lcs.mit.edu
Subject: Re: Scheme as a standard extension language
It sounds like you're saying that you prefer Scheme to Common Lisp
because Scheme is "smaller", but Scheme is missing things that you
need, so you'll have to extend it. Well, if you think about it, this
shows why Common Lisp is the size that it is: it contains a whole lot
of stuff that people have needed from time to time. Once you put in
all the extensions to Scheme that you'll find you want to have, the
difference in size will not be as great.
When people talk about the "size of Common Lisp", whether they be
measuring the size of executable files or the reference manual, they
are really talking about the language plus a huge library of functions
that are useful to some people some of the time.
It is possible to construct a Common Lisp implementation in which an
executable doesn't pay for the parts of the library that it doesn't
use. I have heard that various Lisp implementors, such as Lucid and
Franz and possibly others, have done work in this area, but I don't
know any of the details. The decision of a standard extension
language for the CFI is important. If you really want to find out the
lowdown on this whole topic, I strongly recommend you talk to the
experienced, professional Lisp implementors at such companies, and
see what they can tell you. Of course, there are also experienced
Scheme implementors around, too, who you might want to talk to.
Of course, if you're considering an extended Scheme, you could equally
well consider a subset of Common Lisp.
Despite my role in defining Common Lisp, I do agree that Scheme has
advantages. Its main advantage is that it's more internally clean and
simple; Common Lisp was required to maintain all kinds of
compatibility with older Lisp dialects, whereas the Scheme designers
started from a tabula rasa and worked hard on elegance and simplicity.
The only counterbalancing argument might be that Common Lisp is
becoming more of a "standard", although Scheme is also something of a
standard in its own right; I'm not sure how much this matters in the
CFI decision.
------------------------------
Message-ID: <387CZXC@cs.swarthmore.edu>
Date: 26 Jan 90 19:32:51 GMT
From: Brian Taylor <cbmvax!vu-vlsi!swatsun!taylor@rutgers.edu>
To: scheme@mc.lcs.mit.edu
Subject: Combinators & Compilation
Does anyone out there have machine readable copies of either of the following
two papers?
H.P. Barendregt, M.C.J.D. can Eekelen, J.R.W. Glauert, J.R. Kennaway,
M.J. Plasmeijer and M.R. Sleep.
[1986] Term graph rewriting, Report 87, Department of Computer Science,
University of Nijmegen, and Report SYS-C87-01, School of Information
Systems, University of East Anglia.
P.M. van den Broek, and G.G. van der Hoeven
[1986] Combinatorgraph reduction and the Church-Rosser theorem, preprint
INF-86-15, Department of Informatics, Twente University of
Technology.
A condensed version of the first paper has been published, but I would like
access to the full proofs contained in the original. If anyone could send me
a copy of either of these, or suggest some way of finding paper copies in the
States, I'd greatly appreciate it.
I'd also appreciate references to any particularly valuable articles in the
literature providing a theoretical justification for the use of graph
reduction in the interpretation of combinatory logic and lambda calculus.
Thanks in advance,
Brian
-----------------------------------------------------------------------
| Brian Taylor |internet: taylor@cs.swarthmore.edu |
| Swarthmore College |bitnet: bdt90@swarthmr.bitnet |
| Swarthmore, PA 19081 |uucp: ...rutgers!bpa!swatsun!taylor |
| USA | |
----------------------------------------------------------------------
--
----------------------------------------------------------------------
| Brian Taylor |internet: taylor@cs.swarthmore.edu |
| Swarthmore College |bitnet: bdt90@swarthmr.bitnet |
| Swarthmore, PA 19081 |uucp: ...rutgers!bpa!swatsun!taylor |
------------------------------
End of Scheme Digest
********************
∂29-Jan-90 0059 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #285
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 29 Jan 90 00:58:57 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA07299; Mon, 29 Jan 90 03:55:48 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Mon, 29 Jan 90 03:55:19 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa08055;
29 Jan 90 3:36 EST
Message-Id: <DIGEST.184.900129.031234.15@MC.LCS.MIT.EDU>
Date: 29 Jan 90 03:12:33 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #285
Scheme Digest #285 29 Jan 90 03:12:33 EST
Today's Topics:
2 messages without subjects
----------------------------------------------------------------------
Message-ID: <9001282025.aa23812@mintaka.lcs.mit.edu>
Date: Sun, 28 Jan 90 19:15:47 EST
From: postmaster@att-in.att.com
To: Scheme%lcs.mit.edu@cunyvm.cuny.edu
Mail to `att.att.com!attmail!mhs!envoy!ics.test/pn=_test_group' alias `att!attmail!mhs!envoy!ics.test/pn=_test_group' from 'CUNYVM.CUNY.EDU!Scheme%lcs.mit.edu' failed.
The error message was:
destination unknown or forwarding disallowed
The message began:
Received: from SCF.FUNDP.AC.BE by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 4525; Fri, 26 Jan 90 12:59:37 EST
Received: by BNANDP11 (Mailer R2.02A) id 5839; Fri, 26 Jan 90 16:38:36 +0100
Date: Fri, 26 Jan 90 02:42:30 EST
Reply-To: Scheme%lcs.mit.edu@CUNYVM.CUNY.EDU
Sender: Scheme Programming Language <SCHEME%BNANDP11.BITNET@CUNYVM.CUNY.EDU>
From: Automatic Scheme Digestifier <Scheme-Request%LCS.MIT.EDU@CUNYVM.CUNY.EDU>
Subject: Scheme Digest #282
Comments: To: Scheme@lcs.mit.edu
To: ICSUG TEST GROUP
<attmail!mhs!envoy!ICS.TEST/PN=_TEST_GROUP@ATT.ATT.COM>
Scheme Digest #282 26 Jan 90 02:42:30 EST
Today's Topics:
Scheme as a standard extension language
---------------------------------------------------------------------
Message-ID: <1486@viewlog.UUCP>
Date: 24 Jan 90 23:13:30 GMT
From: Josh Marantz
<zaphod.mps.ohio-state.edu!usc!apple!netcom!stratus!cloud9!viewlog!josh@think.c
om>
To: scheme@mc.lcs.mit.edu
Subject: Scheme as a standard extension language
I'm on a subcommittee of the CAD Framework Initiative (CFI), and we're
working to standardize on a specific standard extension language for
Electrical CAD/CAE applications.
The mission of CFI is "To develop world-wide industry acceptable
guidelines for design automation frameworks which will enable the
coexistence and cooperation of a variety of tools."
The goal of the working group on extension languages is to provide
integrators and users of multi-vendor systems a single extension
language that will work with all their applications.
The obvious analogy is that different flavors of Emacs have compatible
user interfaces and philosophies, but totally incompatible extension
languages (EEL, Mocklisp, Elisp, Teco...). Wouldn't it be nice if
they standardized?
Whether or not you agree with this premise, we are trying to come up
with a standard language (for some definition of "standard") that meets
various criteria. The criteria include:
High Productivity (implies high level language)
Good development environment
Automatic memory management (garbage collection)
Specific runtime call to reclaim memory (collect garbage)
Easy construction of complex data structures
Easy manipulation of strings, lists, and complex data structures
Quick turn around of code changes
Rapid prototyping
Built in debugging capability
Public domain source and commercial products available
Easy to parse EDIF using extension language
Late binding
Dynamic binding
Able to express rules and constraints
Able to construct module generator (to generate cells)
Sequential model of execution (stream i/o)
Standard language with a large user base
Multiple namespaces (packages)
Access to all other parts of framework from extension language
We could try to invent our own language that meets these requirements, but
leveraging off an existing standard is a high priority for us.
The two languages that we've come up with that come closest to meeting
these requirements are Common Lisp and Scheme. Common Lisp is
feature-rich and requires the fewest extensions to provide the
features we need. But it is huge and thereby dictates certain
architectural considerations and platform requirements where it would
be nice to remain more flexible. In particular, it may be desirable
to have several applications running on a workstation, each of which
has its own extension language processor linked in. Correct me if I'm
wrong, but if the extension language is 2 Meg worth of Common Lisp,
then this would not be a design option. My understanding is that
shared libraries might ease the problem, but would not eliminate it.
However, standard Common Lisp (with CLOS and the Pittman error
handler) provide us a nearly complete package that we wouldn't have to
augment. The useful features it provides that Scheme doesn't include:
structure definition (defstruct), error handling, an object/class
system, hash tables, optional strong typing, looping constructs, and
efficient compilation.
Scheme is more elegant and streamlined, but would require a large
number of extensions to supply all the features we need. I couldn't
find many of the required features in R3RS, but I've seen them in
various implementations of Scheme. For example:
Packages MIT-Scheme
Debugging Support MIT-Scheme
Object Oriented Programming XScheme
Simple integration with C Code SIOD
I personally support Scheme as the basis for an extension language,
primarily because it can be implemented without a big memory hit (as was
done with SIOD). It seems to me that even with the extensions we need,
Scheme would still be leaner than Common Lisp. For example, packages and
an object/class system can be trivially implemented with environments.
But what I need to present my case better is some sort of "common"
extension package that can provide the features we require. Is there
an effort out there to define extensions and enhancements that I could
present along with R3RS to the committee? Or should I try to come up
with a "Scheme's greatest hits" collection and suggest that we
standardize on those extensions as well as R3RS?
Any comments from the Scheme and Lisp communities are welcome. If
Common Lisp is not as expensive as I assume, then I'm sure someone
will correct me!
--
Joshua Marantz
Viewlogic Systems, Inc.
cloud9!viewlog!josh@bu-cs.bu.edu
-----------------------------
End of Scheme Digest
********************
------------------------------
Message-ID: <9001282025.aa23813@mintaka.lcs.mit.edu>
Date: Sun, 28 Jan 90 19:19:13 EST
From: postmaster@att-in.att.com
To: Scheme%lcs.mit.edu@cunyvm.cuny.edu
Mail to `att.att.com!attmail!mhs!envoy!ics.test/pn=_test_group' alias `att!attmail!mhs!envoy!ics.test/pn=_test_group' from 'CUNYVM.CUNY.EDU!Scheme%lcs.mit.edu' failed.
The error message was:
destination unknown or forwarding disallowed
The message began:
Received: from SCF.FUNDP.AC.BE by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 7392; Sun, 28 Jan 90 15:00:31 EST
Received: by BNANDP11 (Mailer R2.02A) id 7080; Sun, 28 Jan 90 18:50:30 +0100
Date: Sun, 28 Jan 90 02:12:33 EST
Reply-To: Scheme%lcs.mit.edu@CUNYVM.CUNY.EDU
Sender: Scheme Programming Language <SCHEME%BNANDP11.BITNET@CUNYVM.CUNY.EDU>
From: Automatic Scheme Digestifier <Scheme-Request%LCS.MIT.EDU@CUNYVM.CUNY.EDU>
Subject: Scheme Digest #284
Comments: To: Scheme@lcs.mit.edu
To: ICSUG TEST GROUP
<attmail!mhs!envoy!ICS.TEST/PN=_TEST_GROUP@ATT.ATT.COM>
Scheme Digest #284 28 Jan 90 02:12:33 EST
Today's Topics:
Scheme as a standard extension language
Combinators & Compilation
---------------------------------------------------------------------
Message-ID: <1990Jan27.222837.3997@odi.com>
Date: 27 Jan 90 22:28:37 GMT
From: Dan Weinreb <odi!dlw@uunet.uu.net>
To: scheme@mc.lcs.mit.edu
Subject: Re: Scheme as a standard extension language
It sounds like you're saying that you prefer Scheme to Common Lisp
because Scheme is "smaller", but Scheme is missing things that you
need, so you'll have to extend it. Well, if you think about it, this
shows why Common Lisp is the size that it is: it contains a whole lot
of stuff that people have needed from time to time. Once you put in
all the extensions to Scheme that you'll find you want to have, the
difference in size will not be as great.
When people talk about the "size of Common Lisp", whether they be
measuring the size of executable files or the reference manual, they
are really talking about the language plus a huge library of functions
that are useful to some people some of the time.
It is possible to construct a Common Lisp implementation in which an
executable doesn't pay for the parts of the library that it doesn't
use. I have heard that various Lisp implementors, such as Lucid and
Franz and possibly others, have done work in this area, but I don't
know any of the details. The decision of a standard extension
language for the CFI is important. If you really want to find out the
lowdown on this whole topic, I strongly recommend you talk to the
experienced, professional Lisp implementors at such companies, and
see what they can tell you. Of course, there are also experienced
Scheme implementors around, too, who you might want to talk to.
Of course, if you're considering an extended Scheme, you could equally
well consider a subset of Common Lisp.
Despite my role in defining Common Lisp, I do agree that Scheme has
advantages. Its main advantage is that it's more internally clean and
simple; Common Lisp was required to maintain all kinds of
compatibility with older Lisp dialects, whereas the Scheme designers
started from a tabula rasa and worked hard on elegance and simplicity.
The only counterbalancing argument might be that Common Lisp is
becoming more of a "standard", although Scheme is also something of a
standard in its own right; I'm not sure how much this matters in the
CFI decision.
-----------------------------
Message-ID: <387CZXC@cs.swarthmore.edu>
Date: 26 Jan 90 19:32:51 GMT
From: Brian Taylor <cbmvax!vu-vlsi!swatsun!taylor@rutgers.edu>
To: scheme@mc.lcs.mit.edu
Subject: Combinators & Compilation
Does anyone out there have machine readable copies of either of the following
two papers?
H.P. Barendregt, M.C.J.D. can Eekelen, J.R.W. Glauert, J.R. Kennaway,
M.J. Plasmeijer and M.R. Sleep.
[1986] Term graph rewriting, Report 87, Department of Computer Science,
University of Nijmegen, and Report SYS-C87-01, School of Information
Systems, University of East Anglia.
P.M. van den Broek, and G.G. van der Hoeven
[1986] Combinatorgraph reduction and the Church-Rosser theorem, preprint
INF-86-15, Department of Informatics, Twente University of
Technology.
A condensed version of the first paper has been published, but I would like
access to the full proofs contained in the original. If anyone could send me
a copy of either of these, or suggest some way of finding paper copies in the
States, I'd greatly appreciate it.
I'd also appreciate references to any particularly valuable articles in the
literature providing a theoretical justification for the use of graph
reduction in the interpretation of combinatory logic and lambda calculus.
Thanks in advance,
Brian
-----------------------------------------------------------------------
| Brian Taylor |internet: taylor@cs.swarthmore.edu |
| Swarthmore College |bitnet: bdt90@swarthmr.bitnet |
| Swarthmore, PA 19081 |uucp: ...rutgers!bpa!swatsun!taylor |
| USA | |
----------------------------------------------------------------------
--
----------------------------------------------------------------------
| Brian Taylor |internet: taylor@cs.swarthmore.edu |
| Swarthmore College |bitnet: bdt90@swarthmr.bitnet |
| Swarthmore, PA 19081 |uucp: ...rutgers!bpa!swatsun!taylor |
-----------------------------
End of Scheme Digest
********************
------------------------------
End of Scheme Digest
********************
∂30-Jan-90 0101 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #286
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 30 Jan 90 01:01:53 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA26436; Tue, 30 Jan 90 04:00:46 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Tue, 30 Jan 90 03:58:44 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa00224;
30 Jan 90 3:32 EST
Message-Id: <DIGEST.184.900130.025742.21@MC.LCS.MIT.EDU>
Date: 30 Jan 90 02:57:42 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #286
Scheme Digest #286 30 Jan 90 02:57:42 EST
Today's Topics:
Questions about PC-Scheme (2 messages)
----------------------------------------------------------------------
Message-ID: <7774@sdcsvax.UCSD.Edu>
Date: 30 Jan 90 01:06:13 GMT
From: David Sudbeck <beowulf!sudbeck@sdcsvax.ucsd.edu>
To: scheme@mc.lcs.mit.edu
Subject: Questions about PC-Scheme
Can any in the Scheme community answer a few questions about PC-Scheme
for me?
1) Is there a command in the EDWIN editor to do global replaces of
text?
2) How do you use the UNBIND call? It is a procedure but I can't find it
in the documentation?
3) Is it true there is a 4.0 version of PC-SCHEME bundled with another of
TI's products? What are the differences with this version from the usual
3.03 version?
4) Is there a library of Common-Lisp macros (making PC-SCHEME look like
Common Lisp) available for ftp?
Thanks for any help.
Dave Sudbeck
------------------------------
Message-ID: <1990Jan30.015944.11884@sun.soe.clarkson.edu>
Date: 30 Jan 90 01:59:44 GMT
From: Jason Coughlin <snorkelwacker!usc!zaphod.mps.ohio-state.edu!rpi!image.soe.clarkson.edu!jk0@CS.BU.EDU>
To: scheme@mc.lcs.mit.edu
Subject: Re: Questions about PC-Scheme
From article <7774@sdcsvax.UCSD.Edu>, by sudbeck@beowulf.ucsd.edu (David Sudbeck):
> Can any in the Scheme community answer a few questions about PC-Scheme
> for me?
>
> 1) Is there a command in the EDWIN editor to do global replaces of
> text?
I can't comment on EDWIN because I don't use it. However, I use EMACS
*A LOT*, and you might want to get a real Emacs for the PC. Since you
asked about ftp, ftp to sun.soe.clarkson.edu and grab a copy of
freemacs. Freemacs is a pretty good implementation of Emacs for the
PC (and it's FreeWare :-).
--
Jason Coughlin ( jk0@sun.soe.clarkson.edu , jk0@clutx )
"Every jumbled pile of person has a thinking part that wonders what the
part that isn't thinking isn't thinking of." - They Might Be Giants
------------------------------
End of Scheme Digest
********************
∂31-Jan-90 0017 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #287
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 31 Jan 90 00:17:48 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA15592; Wed, 31 Jan 90 03:17:07 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Wed, 31 Jan 90 03:16:23 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa17200;
31 Jan 90 3:06 EST
Message-Id: <DIGEST.184.900131.024254.27@MC.LCS.MIT.EDU>
Date: 31 Jan 90 02:42:53 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #287
Scheme Digest #287 31 Jan 90 02:42:53 EST
Today's Topics:
Extend-syntax sources (2 messages)
Combinators & Compilation
Scheme in Forth?
X bindings in Scheme?
----------------------------------------------------------------------
Message-ID: <1990Jan30.142352.17622@sun.soe.clarkson.edu>
Date: 30 Jan 90 14:23:52 GMT
From: Jason Coughlin <cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!rpi!image.soe.clarkson.edu!jk0@yale-zoo.arpa>
To: scheme@mc.lcs.mit.edu
Subject: Extend-syntax sources
Does anyone have sources for extend-syntax? I have 2 copies: one
bundled with PC-Scheme and one bundled with MIT-Scheme. However,
the code in them (originally written by R. Kent Dyvbig [sp]) is
REAL dense. I'm looking for either the original (not twisted to fit
on PC-Scheme or MIT-Scheme) from Dyvbig [sorry about that] or a
version no quite so dense. Any ideas?
(The problem is that I'm going to build extend-syntax into my interpreter
and want to do with C code. Trying to re-write that Scheme code is
turning into a major ordeal).
--
Jason Coughlin ( jk0@sun.soe.clarkson.edu , jk0@clutx )
"Every jumbled pile of person has a thinking part that wonders what the
part that isn't thinking isn't thinking of." - They Might Be Giants
------------------------------
Message-ID: <4232@brahma.cs.hw.ac.uk>
Date: 30 Jan 90 11:30:36 GMT
From: Greg Michaelson <mcsun!ukc!edcastle!hwcs!greg@uunet.uu.net>
To: scheme@mc.lcs.mit.edu
Subject: Re: Combinators & Compilation
From article <387CZXC@cs.swarthmore.edu>, by taylor@cs.swarthmore.edu (Brian Taylor):
> I'd also appreciate references to any particularly valuable articles in the
> literature providing a theoretical justification for the use of graph
> reduction in the interpretation of combinatory logic and lambda calculus.
Indeed, is there any evidence that graph reduction will ever be as time/space
efficient as traditional compilation techniques for functional languages
on Von Neumann architectures?
------------------------------
Message-ID: <SJJA-1519-2504.20@nasamail>
Date: 30 Jan 90 19:12:00 GMT
From: GEMINI.ARC.NASA.GOV!/C=CANADA/ADMD=TELECOM.CANADA/ID=ICS.TEST/S=TESTGROUP/@ucbvax.berkeley.edu
To: scheme@mc.lcs.mit.edu
Subject: Scheme in Forth?
I was casually browsing comp.lang.forth a few days ago, and I think that
it was then that I caught an article asking for information about Scheme
in Forth.
Does anyone know of such a magic device, and from where it can be snarfed
(preferably by FTP)? I am curious to see how such a thing would implement
the garbage-collection (or other memory-management) in a Forth virtual
machine, especially on a host-machine like an 8088 Incredibly Bad Machine
Xtra-Terrible clone.
---
Sean Doran
pp ICS TEST GROUP
RFC-822: /C=CANADA/ADMD=TELECOM.CANADA/ID=ICS.TEST/S=TESTGROUP/@gemini.arc.nasa.gov
sdoran%utzbee@zoo.utoronto.ca
UUCP: {uunet,utgpu,utzoo,ucbvax,decuac}!att!attmail!mhs!envoy!ICS.TEST
utzoo!utzbee!sdoran
------------------------------
Message-ID: <34354@iuvax.cs.indiana.edu>
Date: 30 Jan 90 20:33:24 GMT
From: "R. Kent Dybvig" <dyb@iuvax.cs.indiana.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: Extend-syntax sources
>Does anyone have sources for extend-syntax? I have 2 copies: one
>bundled with PC-Scheme and one bundled with MIT-Scheme. However,
>the code in them (originally written by R. Kent Dyvbig [sp]) is
>REAL dense. I'm looking for either the original (not twisted to fit
>on PC-Scheme or MIT-Scheme) from Dyvbig [sorry about that] or a
>version no quite so dense. Any ideas?
I have made three implementations of extend-syntax available on
iuvax.cs.indiana.edu for anonymous ftp. The files are:
pub/extend-syntax.ss: Chez Scheme source code for extend-syntax
pub/mitscheme-extend-syntax.ss: MITScheme compatible version
pub/simple-extend.ss: simpler version
The first two are certainly dense. The third is much simpler, though
the file I found it in was three years old so it may be somewhat out of
date. The mitscheme version is a port of a slightly older version of
the Chez Scheme source code that didn't handle quasiquote within "with"
clauses properly.
If someone will send me current versions for MacScheme or PCScheme, I
will be happy to make them available for ftp access as well.
Kent Dybvig
R. Kent Dybvig | Computer Science Department
dyb@iuvax.cs.indiana.edu | Indiana University
812/855-6486 | Bloomington, IN 47405
------------------------------
Message-ID: <9001310339.AA10361@corwin.CCS.Northeastern.EDU>
Date: Tue, 30 Jan 90 22:39:26 EST
From: Mitchell Wand <wand@corwin.ccs.northeastern.edu>
To: scheme@mc.lcs.mit.edu
CC: wand@corwin.ccs.northeastern.edu
Subject: X bindings in Scheme?
Has anyone attempted to build Scheme bindings for any of the X resource
sets, so I can play with X windows from inside Scheme?
Mitch Wand
wand@corwin.ccs.northeastern.edu
------------------------------
End of Scheme Digest
********************
∂31-Jan-90 1338 @zurich.ai.mit.edu,@mc.lcs.mit.edu:chaynes@iuvax.cs.indiana.edu Minutes of the 4th Scheme standarization meeting
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 31 Jan 90 13:38:25 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA26420; Wed, 31 Jan 90 16:32:21 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Wed, 31 Jan 90 16:31:41 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa14899;
31 Jan 90 16:17 EST
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 31 Jan 90 16:18:33 EST
Received: from iuvax.cs.indiana.edu by mintaka.lcs.mit.edu id aa14751;
31 Jan 90 16:13 EST
Received: by iuvax.cs.indiana.edu
Date: Wed, 31 Jan 90 16:11:55 -0500
From: Chris Haynes <chaynes@iuvax.cs.indiana.edu>
To: scheme-standard@wheaties.ai.mit.edu, rrrs-authors@mc.lcs.mit.edu,
scheme@mc.lcs.mit.edu
Subject: Minutes of the 4th Scheme standarization meeting
Message-Id: <9001311613.aa14751@mintaka.lcs.mit.edu>
IEEE/MCS/P1178 Working Group on Scheme
Unapproved Minutes of the Fourth Meeting
January 19, 1990, San Francisco, CA
The meeting was called to order by Christopher Haynes at about 1:45PM.
The attendees were:
Norman Adams Xerox PARC
Scott Burson Blue Space Foundation
William Clinger University of Oregon
Pavel Curtis Xerox PARC
Ken Dickey Tektronix, Inc.
Kent Dybvig Indiana University
Marc Feeley Brandeis University
Dan Friedman Indiana University
Dick Gabriel Stanford University
John Gateley Texas Instruments
Jed Harris Apple Computer
Christopher Haynes Indiana University
Robert Hieb Indiana University
Roger Kirchner Carleton College
William Maddox U. of California at Berkeley
Sidney Marshal Xerox
James Miller Brandeis University
John D. Ramsdell The MITRE Corporation
Benjamin Schreiber Brandeis University
Guy L. Steele, Jr Thinking Machines Inc
1. The agenda was amended; the changes are reflected by the minutes.
2. John D. Ramsdell was elected secretary.
3. Minutes of the third meeting were accepted with no changes.
4. Reports on R4RS, macros, and ISO.
A. Report on R4RS. (Will Clinger)
R4RS is complete except for the appendix describing macros and the
bibliography.
B. Report on the status of the macro committee. (Will Clinger)
1. Syntactic closures are out of favor. Chris Hanson attempted to
implement EXTEND-SYNTAX using syntactic closures. The attempt
was not entirely successful because of a previously unrecognized
technical problem: in some cases an EXTEND-SYNTAX based on
syntactic closures must know the syntactic role of an identifier
before macro expansion has made that role apparent.
2. A proposal based on a descendent of hygienic macro expansion
has some members of the macro committee confident that a
resolution to the macro impasse is at hand. The current
proposal is due to Jonathan Rees, who modified a proposal by
Will Clinger, who based his proposal on Eugene Kohlbecker's
Ph.D thesis work.
C. Report on the International Standards Organization WG-16. (Dick Gabriel)
WG-16 is not currently interested in Scheme as a basis for an
international standard.
5. Quick review of IEEE standardization procedures. (Chris Haynes)
Resolved: The chair will post instructions to the Scheme notesfiles on
how to request membership in the balloting group for the Scheme standard.
6. Discuss draft P1178/D3.
Many of the agenda items were entered by Sidney Marshall.
A. Consensus: The editors should fix the introduction so that the
definitions of "confirming implementation" and "conforming program"
constrain the implementation to meet the standard.
B. Consensus: No change is needed in the description on pg. 11 of
the "evaluates to" symbol.
C. Consensus: An editorial change shall be made to the section on
disjoint types with "No object satisfies more than one ..."
changed to "Every object satisfies at most one ...".
D. Consensus: The restriction on duplicate entries in CASE key
sets should be removed and the text updated to be consistent
with the derived semantics. That is
(case x ((3.14 3.14159) 'pi) (else '()))
is fine on machines on which (eqv? 3.14 3.14159) => #t, and
key lists are examined inorder to find the first match.
E. Consensus: Add to the text a statement of the form "Assigning
a new value to a variable defined in the initial environment
does not affect the behavior of any procedure defined in the
report."
F. Consensus: Change reference 20 to the second edition of CLtL.
G. Consensus: Change the description of remainder to correctly deal
with the sign of negative zero.
H. Consensus: References to unpublished works should be changed into
references to published works.
Ref 5 --> "The Theory of Numbers," by G H Hardy & E W Wright,
Refs 17 --> William Clinger and Jonathan Rees (editors), The revised↑4
report on the algorithmic language Scheme, University of Oregon
Technical Report CIS-TR-90-02.
Ref 22 --> Thinking Machines Technical Report by Guy Steele, Jr.
Section 1.1 should refer to Steele's master's thesis (MIT AI-TR-474)
for a definition of "properly tail recursive".
The bracketed sentence at the end of Appendix C.3 should removed
and the sentence preceding it changed to refer to William Clinger,
How to read floating point numbers accurately, University of
Oregon Technical Report CIS-TR-90-01.
I. Withdrawn: The word "should" should be eliminated from text.
J. Withdrawn: Definitions should be treated syntactically as
expressions.
K. Moved and rejected: Eliminate CALL-WITH-CURRENT-CONTINUATION
from text.
It was argued that elimination would encourage more people to use
IEEE Scheme as their extension language, but others felt Scheme
without CALL-WITH-CURRENT-CONTINUATION is simply not Scheme.
The vote was three for and eleven against.
L. Withdrawn: Change text so that "(BEGIN)" is a legal expression.
M. Moved and rejected: A key set of a CASE form may not be empty.
N. Moved and rejected: Remove named LET from the text.
O. Discussed and rejected: All parts of lists generated by a
quasiquote expression should be mutable.
P. Moved and accepted: Change the text in the section on symbols to
qualify some of the examples with the phrase "symbols as defined
in this report".
Q. Withdrawn: All conforming implementations must support a minimum
number range.
6. Moved and unanimously accepted: After amendment to conform with the
consensus of this meeting, and other changes deemed non-controversial
by the editors, draft D3 should be submitted to the MSC for public
comment and balloting.
7. Consensus: An ad hoc subcommittee of this working group will
respond to public comments and negative ballots. The members of
this committee will be Chris Hanson, James S. Miller, and John D.
Ramsdell. Another meeting of the working group will be called
if it is felt that the responses recommended by this subcommittee
may be controversial.
8. Moved and accepted: This working group will terminate its activity when
the draft is accepted as a standard, and will reform when necessary to
revise the standard.
9. Moved and unanimously accepted: The committee thanks Christopher Haynes,
the IEEE editors, David H. Bartley, Chris Hanson, and James S. Miller,
and the RnRS editors, Will Clinger and Jonathan Rees.
10. Moved and accepted: Identify the standard draft editors in the text.
The meeting adjourned at 5:45PM.
-- Minutes by John D. Ramsdell, edited by Christopher Haynes.
∂31-Jan-90 2355 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #288
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 31 Jan 90 23:55:31 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA05039; Thu, 1 Feb 90 02:50:51 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Thu, 1 Feb 90 02:50:12 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa08708;
1 Feb 90 2:40 EST
Message-Id: <DIGEST.184.900201.022819.4@MC.LCS.MIT.EDU>
Date: 1 Feb 90 02:28:19 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #288
Scheme Digest #288 1 Feb 90 02:28:19 EST
Today's Topics:
Extend-syntax sources
X bindings in Scheme? (2 messages)
Minutes of the 4th Scheme standarization meeting
Combinators & Compilation
----------------------------------------------------------------------
Message-ID: <4445@brazos.Rice.edu>
Date: 31 Jan 90 15:51:51 GMT
From: Bruce Duba <aten!duba@rice.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: Extend-syntax sources
In article <1990Jan30.142352.17622@sun.soe.clarkson.edu> jk0@image.soe.clarkson.edu (Jason Coughlin) writes:
>Does anyone have sources for extend-syntax?
> ...
>(The problem is that I'm going to build extend-syntax into my interpreter
>and want to do with C code. Trying to re-write that Scheme code is
>turning into a major ordeal).
The best source to understand a (simple) extend-syntax processor and
how to build it is Eugene Kohlbecker's original publciation:
Kohlbecker, E. and M. Wand. Macro-by-example: deriving syntactic
transformations from their specifications. In Proc. 14th ACM
Symposium on Principles of Programming Languages, 1987, 77--85.
The most complete description of extend-syntax todate is Kohlbecker's
dissertation:
Kohlbecker, E. Syntactic Extensions in the Programming Language Lisp.
Ph.D. dissertation, Indiana University, 1986.
-- Bruce Duba & Matthias Felleisen
------------------------------
Message-ID: <9001311838.AA02827@jove.pa.dec.com>
Date: Wed, 31 Jan 90 10:38:12 PST
From: bartlett@wrl.dec.com
To: Scheme@lcs.mit.edu
CC: bartlett@wrl.dec.com
Subject: Re: X bindings in Scheme?
The Scheme->C compiler and interpreter done at DECWRL provides Scheme
interfaces to the C library for X11R3. If it's in "X Window System C
Library and Protocol Reference", Scheifler, Gettys & Newman, then it's
available. Using the interfaces, the "Hello World" program from Oliver
Jone's book "Introduction to the X Window System" can be written:
(define (HELLO-WORLD)
(let* ((hello "Hello, World")
(hi "Hi!")
(dpy (let ((x (xopendisplay "")))
(if (null-pointer? x)
(error 'hello-world "DISPLAY is not defined"))
x))
(screen (xdefaultscreen dpy))
(background (xwhitepixel dpy screen))
(foreground (xblackpixel dpy screen))
(window (xcreatesimplewindow dpy (xdefaultrootwindow dpy)
200 300 350 250 5 foreground background))
(gc (xcreategc dpy window 0 (make-xgcvalues)))
(event (make-xevent)))
(xstorename dpy window
"Hello, World in Scheme->C using X11's Xlib")
(xseticonname dpy window "hello")
(xsetbackground dpy gc background)
(xsetforeground dpy gc foreground)
(xselectinput dpy window
(bit-or buttonpressmask keypressmask exposuremask))
(xmapraised dpy window)
(let loop ()
(ynextevent dpy event)
(cond ((eq? (xevent-type event) expose)
(xdrawimagestring (xevent-xexpose-display event)
(xevent-xexpose-window event) gc 50 50
hello (string-length hello))
(loop))
((eq? (xevent-type event) mappingnotify)
(xrefreshkeyboardmapping event)
(loop))
((eq? (xevent-type event) buttonpress)
(xdrawimagestring (xevent-xbutton-display event)
(xevent-xbutton-window event) gc
(xevent-xbutton-x event) (xevent-xbutton-y event)
hi (string-length hi))
(loop))
((and (eq? (xevent-type event) keypress)
(equal? (ylookupstring event) "q"))
(xfreegc dpy gc)
(xdestroywindow dpy window)
(xclosedisplay dpy))
(else (loop))))))
------------------------------
Message-ID: <9001311613.aa14751@mintaka.lcs.mit.edu>
Date: Wed, 31 Jan 90 16:11:55 -0500
From: Chris Haynes <chaynes@iuvax.cs.indiana.edu>
To: scheme-standard@wheaties.ai.mit.edu, rrrs-authors@MC.lcs.mit.edu,
scheme@MC.lcs.mit.edu
Subject: Minutes of the 4th Scheme standarization meeting
IEEE/MCS/P1178 Working Group on Scheme
Unapproved Minutes of the Fourth Meeting
January 19, 1990, San Francisco, CA
The meeting was called to order by Christopher Haynes at about 1:45PM.
The attendees were:
Norman Adams Xerox PARC
Scott Burson Blue Space Foundation
William Clinger University of Oregon
Pavel Curtis Xerox PARC
Ken Dickey Tektronix, Inc.
Kent Dybvig Indiana University
Marc Feeley Brandeis University
Dan Friedman Indiana University
Dick Gabriel Stanford University
John Gateley Texas Instruments
Jed Harris Apple Computer
Christopher Haynes Indiana University
Robert Hieb Indiana University
Roger Kirchner Carleton College
William Maddox U. of California at Berkeley
Sidney Marshal Xerox
James Miller Brandeis University
John D. Ramsdell The MITRE Corporation
Benjamin Schreiber Brandeis University
Guy L. Steele, Jr Thinking Machines Inc
1. The agenda was amended; the changes are reflected by the minutes.
2. John D. Ramsdell was elected secretary.
3. Minutes of the third meeting were accepted with no changes.
4. Reports on R4RS, macros, and ISO.
A. Report on R4RS. (Will Clinger)
R4RS is complete except for the appendix describing macros and the
bibliography.
B. Report on the status of the macro committee. (Will Clinger)
1. Syntactic closures are out of favor. Chris Hanson attempted to
implement EXTEND-SYNTAX using syntactic closures. The attempt
was not entirely successful because of a previously unrecognized
technical problem: in some cases an EXTEND-SYNTAX based on
syntactic closures must know the syntactic role of an identifier
before macro expansion has made that role apparent.
2. A proposal based on a descendent of hygienic macro expansion
has some members of the macro committee confident that a
resolution to the macro impasse is at hand. The current
proposal is due to Jonathan Rees, who modified a proposal by
Will Clinger, who based his proposal on Eugene Kohlbecker's
Ph.D thesis work.
C. Report on the International Standards Organization WG-16. (Dick Gabriel)
WG-16 is not currently interested in Scheme as a basis for an
international standard.
5. Quick review of IEEE standardization procedures. (Chris Haynes)
Resolved: The chair will post instructions to the Scheme notesfiles on
how to request membership in the balloting group for the Scheme standard.
6. Discuss draft P1178/D3.
Many of the agenda items were entered by Sidney Marshall.
A. Consensus: The editors should fix the introduction so that the
definitions of "confirming implementation" and "conforming program"
constrain the implementation to meet the standard.
B. Consensus: No change is needed in the description on pg. 11 of
the "evaluates to" symbol.
C. Consensus: An editorial change shall be made to the section on
disjoint types with "No object satisfies more than one ..."
changed to "Every object satisfies at most one ...".
D. Consensus: The restriction on duplicate entries in CASE key
sets should be removed and the text updated to be consistent
with the derived semantics. That is
(case x ((3.14 3.14159) 'pi) (else '()))
is fine on machines on which (eqv? 3.14 3.14159) => #t, and
key lists are examined inorder to find the first match.
E. Consensus: Add to the text a statement of the form "Assigning
a new value to a variable defined in the initial environment
does not affect the behavior of any procedure defined in the
report."
F. Consensus: Change reference 20 to the second edition of CLtL.
G. Consensus: Change the description of remainder to correctly deal
with the sign of negative zero.
H. Consensus: References to unpublished works should be changed into
references to published works.
Ref 5 --> "The Theory of Numbers," by G H Hardy & E W Wright,
Refs 17 --> William Clinger and Jonathan Rees (editors), The revised↑4
report on the algorithmic language Scheme, University of Oregon
Technical Report CIS-TR-90-02.
Ref 22 --> Thinking Machines Technical Report by Guy Steele, Jr.
Section 1.1 should refer to Steele's master's thesis (MIT AI-TR-474)
for a definition of "properly tail recursive".
The bracketed sentence at the end of Appendix C.3 should removed
and the sentence preceding it changed to refer to William Clinger,
How to read floating point numbers accurately, University of
Oregon Technical Report CIS-TR-90-01.
I. Withdrawn: The word "should" should be eliminated from text.
J. Withdrawn: Definitions should be treated syntactically as
expressions.
K. Moved and rejected: Eliminate CALL-WITH-CURRENT-CONTINUATION
from text.
It was argued that elimination would encourage more people to use
IEEE Scheme as their extension language, but others felt Scheme
without CALL-WITH-CURRENT-CONTINUATION is simply not Scheme.
The vote was three for and eleven against.
L. Withdrawn: Change text so that "(BEGIN)" is a legal expression.
M. Moved and rejected: A key set of a CASE form may not be empty.
N. Moved and rejected: Remove named LET from the text.
O. Discussed and rejected: All parts of lists generated by a
quasiquote expression should be mutable.
P. Moved and accepted: Change the text in the section on symbols to
qualify some of the examples with the phrase "symbols as defined
in this report".
Q. Withdrawn: All conforming implementations must support a minimum
number range.
6. Moved and unanimously accepted: After amendment to conform with the
consensus of this meeting, and other changes deemed non-controversial
by the editors, draft D3 should be submitted to the MSC for public
comment and balloting.
7. Consensus: An ad hoc subcommittee of this working group will
respond to public comments and negative ballots. The members of
this committee will be Chris Hanson, James S. Miller, and John D.
Ramsdell. Another meeting of the working group will be called
if it is felt that the responses recommended by this subcommittee
may be controversial.
8. Moved and accepted: This working group will terminate its activity when
the draft is accepted as a standard, and will reform when necessary to
revise the standard.
9. Moved and unanimously accepted: The committee thanks Christopher Haynes,
the IEEE editors, David H. Bartley, Chris Hanson, and James S. Miller,
and the RnRS editors, Will Clinger and Jonathan Rees.
10. Moved and accepted: Identify the standard draft editors in the text.
The meeting adjourned at 5:45PM.
-- Minutes by John D. Ramsdell, edited by Christopher Haynes.
------------------------------
Message-ID: <1277@sys.uea.ac.uk>
Date: 31 Jan 90 17:40:21 GMT
From: Richard Kennaway CMP RA <mcsun!ukc!sys.uea!jrk@uunet.uu.net>
To: scheme@mc.lcs.mit.edu
Subject: Re: Combinators & Compilation
In article <4232@brahma.cs.hw.ac.uk> greg@cs.hw.ac.uk (Greg Michaelson) writes:
>Indeed, is there any evidence that graph reduction will ever be as time/space
>efficient as traditional compilation techniques for functional languages
>on Von Neumann architectures?
Surely graph reduction *is* the traditional technique. What did you have
in mind?
--
Richard Kennaway SYS, University of East Anglia, Norwich, U.K.
Internet: jrk@sys.uea.ac.uk uucp: ...mcvax!ukc!uea-sys!jrk
------------------------------
Message-ID: <6599@ubc-cs.UUCP>
Date: 31 Jan 90 21:53:28 GMT
From: Vincent Manis <snorkelwacker!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!van-bc!ubc-cs!manis@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: X bindings in Scheme?
Xlib is pretty easy to call from your favourite Scheme. I'm desultorily
working on a simple Xlib interface from Chez Scheme; and MIT CScheme has
(almost?) full Xlib support as well, as I recollect. Any Scheme which
allows you to call C procedures will support Xlib ok.
Actually, what I'd like is Xt (or, even better, Motif) from Scheme. It
would be even better to be able to write widgets in Scheme! The problem
is that the architecture of Xt involves a lot of callbacks, and,
generally (unless you're using the DECWRL compiler) you can't call
Scheme from C.
Has anybody had any thoughts on this?
--
\ Vincent Manis <manis@cs.ubc.ca> "There is no law that vulgarity and
\ Department of Computer Science literary excellence cannot coexist."
/\ University of British Columbia -- A. Trevor Hodge
/ \ Vancouver, BC, Canada V6T 1W5 (604) 228-2394
------------------------------
End of Scheme Digest
********************
∂01-Feb-90 1246 @zurich.ai.mit.edu,@mc.lcs.mit.edu:chaynes@iuvax.cs.indiana.edu Scheme standard balloting
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Feb 90 12:45:54 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA03209; Thu, 1 Feb 90 15:40:38 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Thu, 1 Feb 90 15:40:05 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa02240;
1 Feb 90 15:23 EST
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 1 Feb 90 15:23:38 EST
Received: from iuvax.cs.indiana.edu by mintaka.lcs.mit.edu id aa01983;
1 Feb 90 15:17 EST
Received: by iuvax.cs.indiana.edu
Date: Thu, 1 Feb 90 15:16:59 -0500
From: Chris Haynes <chaynes@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu, scheme-standard@wheaties.ai.mit.edu,
scheme@mc.lcs.mit.edu
Subject: Scheme standard balloting
Message-Id: <9002011517.aa01983@mintaka.lcs.mit.edu>
This note is for those who are interested in balloting on the IEEE
draft standard for Scheme.
As noted in the recently posted minutes, there was consensus at the
4th Scheme standardization meeting that the draft (with minor
revision) is ready for public comment and balloting. If things
proceed on schedule, the IEEE Microprocessor Standards Committee (MSC)
will approve the draft for balloting at their March 12th meeting and
ballots will be mailed about April 1st. At least 75% of the ballots
must be returned within 30 days for the ballot to be valid, and at
least 75% of the non-abstention ballots must be affirmative for the
draft to become a standard. (If all goes smoothly, the draft could
then be approved as an IEEE standard on September 28th.)
Membership in the balloting group may be requested by emailing the
form at the end of this note to camp@csc.ti.com. That's Clyde Camp,
the MSC chair. If necessary, his mail address is: Texas Instruments,
Inc., 2313 Merrimac Dr., Plano, TX 75075. Comments on draft
standards are welcome from anyone, whether they participate in
balloting or not.
On the request form for balloting group membership, if you are
significantly involved in developing or maintaining a Scheme
implementation, interest category P1178-p is appropriate. If you do a
great deal of programming in Scheme, P1178-u is appropriate.
Otherwise, P1178-gi is appropriate---this should include most
academics (such as myself) who use Scheme for teaching and research.
If more than one category is appropriate, you may pick any one that
is. However, in choosing a category, you may wish to keep in mind the
following IEEE (and ANSI) rule: for balloting to be valid, not more
than 50% of the ballots may be from individuals in the same interest
category, except for the general interest category, on which there is
no limit. Thus, when in doubt, it may be best to choose P1178-gi.
With few exceptions, balloting body members must be IEEE or IEEE
Computer Society (CS) members. You do not have to be a member at the
time you request membership on the balloting body, but you have to be
a member before your ballot is returned, and it takes 3 to 6 weeks for
membership applications to be processed. Thus if you want to be in
the balloting body and you are not already an IEEE or CS member,
YOU MUST APPLY FOR MEMBERSHIP SOON.
Membership information and applications may be obtained by calling
800-678-IEEE or 201-562-5528. IEEE membership is $77, but ACM members
can join the CS for only $13. If you can locate an officer of a local
chapter of the IEEE or CS, they should have applications. You may
also email Clyde Camp (camp@csc.ti.com) a request and he will FAX you
a CS application. CS membership applications may be FAXed (both
sides, with credit card information) to David Barber at 714-821-4010.
Alternatively, CS applications with check/cash/money order/plastic
number can be mailed, for rapid processing, in to:
IEEE Computer Society
10662 Los Vaqueros Circle
Los Alamitos, CA 90720-2578
Attn: David Barber
Applications must be signed by an existing IEEE or CS member (as a
"recommender"). If you can't find such a person locally, you may send
your application to me and I will provide the signature.
Christopher Haynes, Scheme Working Group Chair
Computer Science Department
Indiana University
Bloomington, IN 47405
Phone: 812-855-33767
Fax: 812-855-4829
Internet: chaynes@iuvax.cs.indiana.edu
======================== CUT HERE ===================================
=================================================================
= Sponsor Application Form =
= for =
= Microcomputer and Microprocessor Standards Subcommittee =
=================================================================
Instructions/notes:
1) The fields marked * are optional, but they help us locate
you if there is a problem.
2) If you have applied but not yet received a membership
number from the IEEE or Computer Society, please enter the
application date in that field.
3) There is no additional fee for Sponsor Membership
4) Under interest, put P1178-gi for general interest/academic
P1178-u for user
P1178-p for producer
P1178-0 for other (and specify other)
Name:
Title:
Company:
Street Address:
City,State:
Zip-code:
Country: USA
Business Phone:
*Home Phone:
*FAX Phone:
IEEE/CS Membership Number:
*E-mail address:
Interests: P1178
YES___ NO___ Please add me to the MSC mailing list
YES___ NO___ I am interested in other language related standards.
YES___ NO___ I am interested in other bus related standards.
YES___ NO___ I am interested in other microprocessor related standards.
∂01-Feb-90 2339 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #289
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Feb 90 23:39:21 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA12319; Fri, 2 Feb 90 02:36:28 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Fri, 2 Feb 90 02:35:47 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa24319;
2 Feb 90 2:29 EST
Message-Id: <DIGEST.184.900202.021326.11@MC.LCS.MIT.EDU>
Date: 2 Feb 90 02:13:26 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #289
Scheme Digest #289 2 Feb 90 02:13:26 EST
Today's Topics:
X bindings in Scheme [long]
Scheme standard balloting
Scheme as a standard extension language
----------------------------------------------------------------------
Message-ID: <9002011531.AA14140@tub.UUCP>
Date: Thu, 1 Feb 90 16:31:13 +0100
From: Oliver Laumann <net%TUB.BITNET@mitvma.mit.edu>
To: Scheme@lcs.mit.edu
CC: manis@cs.ubc.ca
Subject: Re: X bindings in Scheme [long]
> Actually, what I'd like is Xt (or, even better, Motif) from Scheme. It
> would be even better to be able to write widgets in Scheme! The problem
> is that the architecture of Xt involves a lot of callbacks, and,
> generally (unless you're using the DECWRL compiler) you can't call
> Scheme from C.
The `Elk' Scheme interpreter provides an interface to the Motif widget
set. It allows you to interactively `explore' the Motif widgets.
Here is a small example program that allows you to set up and use Motif
pulldown, popup, and option menus:
----------------------------------------------------------------
;;; -*-Scheme-*-
(define (create-menu type parent args)
(define grand-parent (widget-parent parent))
(if (and (not (eq? grand-parent 'none))
(eq? (widget-class grand-parent) (find-class 'menu-shell)))
(set! parent grand-parent))
(let ((shell (create-popup-shell (find-class 'menu-shell)
parent 'width 100 'height 100)))
(apply create-widget (find-class 'row-column) shell
'row-column-type type args)))
(define (create-popup-menu parent . args)
(create-menu 'menu-popup parent args))
(define (create-pulldown-menu parent . args)
(create-menu 'menu-pulldown parent args))
(define (create-option-menu parent . args)
(apply create-managed-widget (find-class 'row-column) parent
'row-column-type 'menu-option args))
(define (create-cascade-pulldown parent pulldown . args)
(let ((button (create-managed-widget (find-class 'cascade-button) parent)))
(set-values! button 'sub-menu-id pulldown)
(apply set-values! button args)
button))
(define (menu-add-item! type menu args)
(let ((item (create-managed-widget (find-class type) menu)))
(apply set-values! item args)
item))
(define (menu-add-label! menu . args)
(menu-add-item! 'label menu args))
(define (menu-add-separator! menu . args)
(menu-add-item! 'separator menu args))
(define (menu-add-button! menu . args)
(menu-add-item! 'push-button menu args))
----------------------------------------------------------------
The following is a small example how you would use the above module to
create a popup menu:
----------------------------------------------------------------
(require 'motif)
(load-widgets shell row-column cascade-button push-button label separator
drawing-area)
(load 'menu-stuff)
(define con (create-context))
(define dpy (initialize-display con #f 'popup 'demo))
(define top (create-shell 'popup 'demo (find-class 'application-shell) dpy))
(define w (create-managed-widget (find-class 'drawing-area) top))
(set-values! w 'width 350 'height 100)
(define menu (create-popup-menu w 'which-button 1))
(menu-add-label! menu 'label-string "Popup menu" 'font-list "9x15")
(menu-add-separator! menu)
(menu-add-button! menu 'label-string "item 1")
(menu-add-button! menu 'label-string "item 2")
(menu-add-button! menu 'label-string "item 3")
(menu-add-separator! menu)
(define quit-button (menu-add-button! menu 'label-string "quit"))
(add-callback quit-button 'activate-callback (lambda args (exit)))
(popup-menu-attach-to! menu w)
(realize-widget top)
(context-main-loop con)
----------------------------------------------------------------
If you have any questions about Elk drop me a letter.
Regards,
--
Oliver Laumann net@TUB.BITNET net@tub.cs.tu-berlin.de net@tub.UUCP
------------------------------
Message-ID: <9002011517.aa01983@mintaka.lcs.mit.edu>
Date: Thu, 1 Feb 90 15:16:59 -0500
From: Chris Haynes <chaynes@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu, scheme-standard@wheaties.ai.mit.edu,
scheme@mc.lcs.mit.edu
Subject: Scheme standard balloting
This note is for those who are interested in balloting on the IEEE
draft standard for Scheme.
As noted in the recently posted minutes, there was consensus at the
4th Scheme standardization meeting that the draft (with minor
revision) is ready for public comment and balloting. If things
proceed on schedule, the IEEE Microprocessor Standards Committee (MSC)
will approve the draft for balloting at their March 12th meeting and
ballots will be mailed about April 1st. At least 75% of the ballots
must be returned within 30 days for the ballot to be valid, and at
least 75% of the non-abstention ballots must be affirmative for the
draft to become a standard. (If all goes smoothly, the draft could
then be approved as an IEEE standard on September 28th.)
Membership in the balloting group may be requested by emailing the
form at the end of this note to camp@csc.ti.com. That's Clyde Camp,
the MSC chair. If necessary, his mail address is: Texas Instruments,
Inc., 2313 Merrimac Dr., Plano, TX 75075. Comments on draft
standards are welcome from anyone, whether they participate in
balloting or not.
On the request form for balloting group membership, if you are
significantly involved in developing or maintaining a Scheme
implementation, interest category P1178-p is appropriate. If you do a
great deal of programming in Scheme, P1178-u is appropriate.
Otherwise, P1178-gi is appropriate---this should include most
academics (such as myself) who use Scheme for teaching and research.
If more than one category is appropriate, you may pick any one that
is. However, in choosing a category, you may wish to keep in mind the
following IEEE (and ANSI) rule: for balloting to be valid, not more
than 50% of the ballots may be from individuals in the same interest
category, except for the general interest category, on which there is
no limit. Thus, when in doubt, it may be best to choose P1178-gi.
With few exceptions, balloting body members must be IEEE or IEEE
Computer Society (CS) members. You do not have to be a member at the
time you request membership on the balloting body, but you have to be
a member before your ballot is returned, and it takes 3 to 6 weeks for
membership applications to be processed. Thus if you want to be in
the balloting body and you are not already an IEEE or CS member,
YOU MUST APPLY FOR MEMBERSHIP SOON.
Membership information and applications may be obtained by calling
800-678-IEEE or 201-562-5528. IEEE membership is $77, but ACM members
can join the CS for only $13. If you can locate an officer of a local
chapter of the IEEE or CS, they should have applications. You may
also email Clyde Camp (camp@csc.ti.com) a request and he will FAX you
a CS application. CS membership applications may be FAXed (both
sides, with credit card information) to David Barber at 714-821-4010.
Alternatively, CS applications with check/cash/money order/plastic
number can be mailed, for rapid processing, in to:
IEEE Computer Society
10662 Los Vaqueros Circle
Los Alamitos, CA 90720-2578
Attn: David Barber
Applications must be signed by an existing IEEE or CS member (as a
"recommender"). If you can't find such a person locally, you may send
your application to me and I will provide the signature.
Christopher Haynes, Scheme Working Group Chair
Computer Science Department
Indiana University
Bloomington, IN 47405
Phone: 812-855-33767
Fax: 812-855-4829
Internet: chaynes@iuvax.cs.indiana.edu
======================== CUT HERE ===================================
=================================================================
= Sponsor Application Form =
= for =
= Microcomputer and Microprocessor Standards Subcommittee =
=================================================================
Instructions/notes:
1) The fields marked * are optional, but they help us locate
you if there is a problem.
2) If you have applied but not yet received a membership
number from the IEEE or Computer Society, please enter the
application date in that field.
3) There is no additional fee for Sponsor Membership
4) Under interest, put P1178-gi for general interest/academic
P1178-u for user
P1178-p for producer
P1178-0 for other (and specify other)
Name:
Title:
Company:
Street Address:
City,State:
Zip-code:
Country: USA
Business Phone:
*Home Phone:
*FAX Phone:
IEEE/CS Membership Number:
*E-mail address:
Interests: P1178
YES___ NO___ Please add me to the MSC mailing list
YES___ NO___ I am interested in other language related standards.
YES___ NO___ I am interested in other bus related standards.
YES___ NO___ I am interested in other microprocessor related standards.
------------------------------
Message-ID: <131091@sun.Eng.Sun.COM>
Date: 1 Feb 90 20:44:29 GMT
From: Cris Perdue <clam!cperdue@sun.com>
To: scheme@mc.lcs.mit.edu
Subject: Re: Scheme as a standard extension language
Dan,
It is possible in principle to make small Common Lisp applications by
using just part of the language, but there is a problem. Common Lisp
defines no layers, so it is impossible to decide which parts of the
language can be avoided to reduce the size of an application. I
believe that most implementations are rather intertwined: support for
one language feature tends to rely on more of the rest of the language
than one might imagine. Many of these dependencies can be eliminated
if need be, and if we know which ones to eliminate.
One big advantage of Scheme is that the base language is such a layer.
Also, when one uses a language plus a set of libraries, it is usually
possible to find out the dependencies among the libraries and to find
out what features require large amounts of runtime support.
This is in addition to the benefits Scheme provides by not carrying
around a lot of features for backward compatibility. The
implementations become smaller and the language becomes intellectually
simpler and cleaner.
------------------------------
End of Scheme Digest
********************
∂02-Feb-90 2357 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #290
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 2 Feb 90 23:57:27 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA01765; Sat, 3 Feb 90 02:52:08 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Sat, 3 Feb 90 02:51:31 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa14960;
3 Feb 90 2:42 EST
Message-Id: <DIGEST.184.900203.022055.5@MC.LCS.MIT.EDU>
Date: 3 Feb 90 02:20:55 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #290
Scheme Digest #290 3 Feb 90 02:20:55 EST
Today's Topics:
Combinators & Compilation
X bindings in Scheme?
X bindings in Scheme [long]
2 messages without subjects
----------------------------------------------------------------------
Message-ID: <1282@sys.uea.ac.uk>
Date: 2 Feb 90 13:15:39 GMT
From: Richard Kennaway CMP RA <eru!luth!sunic!mcsun!ukc!sys.uea!jrk@bloom-beacon.mit.edu>
To: scheme@MC.lcs.mit.edu
Subject: Re: Combinators & Compilation
In message <387CZXC@cs.swarthmore.edu>, taylor@cs.swarthmore.edu (Brian
Taylor) writes:
> I'd also appreciate references to any particularly valuable articles in the
> literature providing a theoretical justification for the use of graph
> reduction in the interpretation of combinatory logic and lambda calculus.
I wont attempt to rank the following references by value, but here are those
I know of, besides the two cited by Taylor.
For graph reduction of the lambda calculus, the original reference is
%A Wadsworth, C.
%T Semantics and pragmatics of the lambda calculus
%R D.Phil. thesis
%I Programming Research Group, Oxford University
%D 1971
%X address of PRG is 8-11 Keble Road, Oxford OX1 3QD, U.K.
This describes a graph rewriting implementation of lambda calculus and proves
it correct. It does not achieve "optimal" sharing in Levy's sense (see
Barendregt's book on the lambda calculus for what this means); this has
recently been done by:
%A Lamping, John
%T An algorithm for optimal lambda calculus reduction
%B POPL 90 conference
%D 1990 January
%A Lamping, John
%T An algorithm for optimal lambda calculus reduction
%R unpublished
%I Xerox PARC
%D 1989
%X A longer version of the POPL paper, with more proofs.
The question of whether the bookkeeping overhead with Lamping's method
outweighs the improvement in sharing it gains is not yet settled.
For graph rewriting implementation of functional languages, see:
%A Peyton-Jones, S.L.
%T The Implementation of Functional Languages
%I Prentice-Hall
%D 1987
For the optimality properties of combinator graph reduction, there is a
series of three papers by Staples (which actually prove it for regular term
graph rewrite systems, of which combinatory logic is an example).
%A Staples, John
%T Computation on graph-like expressions
%J Th.Comp.Sci.
%V 10
%P 171-185
%D 1980
%A Staples, John
%T Optimal evaluations of graph-like expressions
%J Th.Comp.Sci.
%V 10
%P 297-316
%D 1980
%A Staples, John
%T Speeding up subtree replacement systems
%J Th.Comp.Sci.
%V 11
%P 39-47
%D 1980
Other references for the correctness of combinator graph reduction:
%A Lester, David
%T Combinator graph reduction: a congruence and its applications
%R D.Phil thesis, Technical Monograph PRG-73
%D 1989
%I Programming Research Group, Oxford University
%X (from the abstract) "This thesis may be read as a formal mathematical proof
that the G-machine is correct with respect to a denotational semantic
specification of a simple language. ... The G-machine is shown to be a
representation of the combinator graph reduction operational model."
%A Farmer, William M.
%A Ramsdell, John D.
%A Watro, Ronald J.
%T A correctness proof for combinator reduction with cycles
%R Report M88-53
%I MITRE
%D 1988 November
%A Farmer, William M.
%A Watro, Ronald J.
%T Redex capturing in term graph rewriting
%R unpublished
%I MITRE
%D 1989 June 16
The address of MITRE is:
The MITRE Corporation
Bedford
Massachusetts
U.S.A.
There are two papers using category theory to prove the same result:
%A Raoult, J.C.
%T On graph rewritings
%J Th.Comp.Sci.
%V 32
%P 1-24
%D 1984
%A Kennaway, J.R.
%T On 'On graph rewritings'
%J Th.Comp.Sci.
%V 52
%P 37-58
%D 1987
%X See also the minor corrigendum in v.61, pp.317-320 (but only if you really
need to study the proofs in detail).
The paper Taylor cited by van den Broek and van der Hoeven is based on a
different category-theoretic approach to general graph rewriting, developed by
the 'Berlin school' - see various papers in the following volumes:
Proc. (1st, 2nd, 3rd) Int. Workshop on Graph Grammars and their application to
computer science, eds. H.Ehrig et al (different als for the three volumes)
1978, 1982, 1986
Springer-Verlag LNCS 73, 153, 291
There will be a 4th conference in this series in Bremen, March 5-9 this year.
Proc. Int. Workshop WG80 on Graph Theoretic Concepts in Computer Science
ed. H. Noltemeier
Springer-Verlag LNCS 100, 1980.
These conferences are concerned with graph rewriting in general, not just the
particular application to functional language implementation. For the latter,
see
Proc. Workshop on Graph Reduction
eds. J.H. Fasel and R.M.Keller
Springer-Verlag LNCS 279, 1986.
There is also a paper either by v.d.Broek and v.d.Hoeven or their colleagues
at Twente on the relationship between the two different category-theoretic
definitions, but I can't find the exact reference at the moment.
The subject is also discussed in Revesz's book "Lambda-calculus,
Combinators, and Functional Programming".
It's some time since I last saw someone ask what LNCS means, but just in case,
it stands for "Lecture Notes in Computer Science".
--
Richard Kennaway SYS, University of East Anglia, Norwich, U.K.
Internet: jrk@sys.uea.ac.uk uucp: ...mcvax!ukc!uea-sys!jrk
------------------------------
Message-ID: <9002021501.AA24590@heike.informatik.uni-dortmund.de>
Date: Fri, 2 Feb 90 16:01:19 +0100
From: Holger Muenx <muenx@heike.informatik.uni-dortmund.de>
To: scheme@ai.mit.edu
Hi!
I just looked at the sources of MIT-Scheme because I thought of porting
it to an Amiga. (Yes, yes, I know, you are only working on REAL computers.
But I think there are many students who have an Amiga and want to have
a scheme for it. At least in Dortmund there is a demand for scheme on
an Amiga as the beginner's course is about scheme.)
The problem is that your scheme is very big (maybe huge is the better
word) so there is no possibility to transfer it to my Amiga. I must
copy it via kermit to an ST and after that it can be copied to my Amiga -
for all sources this would take hours.
So my question: Is there any smaller version of MIT-Scheme. If yes: where
can I get it? Or do you know anyone who tried to port Scheme to an Amiga?
Sorry for my horrible English, thank you for your interest, ciao
-Holger
----------------------------------------------------------------------------
Holger Muenx muenx@heike.informatik.uni-dortmund.de
IRB
Universitaet Dortmund
4600 Dortmund
West-Germany
------------------------------
Message-ID: <34721@iuvax.cs.indiana.edu>
Date: 2 Feb 90 16:09:31 GMT
From: Sho-Huan Simon Tung <stung@iuvax.cs.indiana.edu>
To: scheme@MC.lcs.mit.edu
Subject: Re: X bindings in Scheme?
In article <6599@ubc-cs.UUCP> manis@cs.ubc.ca (Vincent Manis) writes:
>Actually, what I'd like is Xt (or, even better, Motif) from Scheme. It
>would be even better to be able to write widgets in Scheme! The problem
>is that the architecture of Xt involves a lot of callbacks, and,
>generally (unless you're using the DECWRL compiler) you can't call
>Scheme from C.
I have found a way to get around the problem. The trick is:
- use a vector to store the Scheme callback functions and client_data.
- use the index to the vector to communicate between Scheme and C.
- use a "standard_callback" function (written in C). standard_callback's
client data will always be the index to the vector. If this callback
is called by Xt it simply set a few flags which indicates information
about widget-id, client_data (the index), and call_data.
- XtMainloop need to be written in Scheme which simply polls the flags
while looping. (if callback occured, use the index to find the Schems
callback function and call it with the desired data.)
Simon Tung
Department of Computer Science
Indiana University
------------------------------
Message-ID: <9002022218.AA03417@zurich.ai.mit.edu>
Date: Fri, 2 Feb 90 17:18:38 est
From: "Sameer E. Shalaby" <sameer@zurich.ai.mit.edu>
To: scheme@zurich.ai.mit.edu
Subject: YACC
Is there a YACC version written in Scheme or Lisp?
Thank you.
- Sameer -
------------------------------
Message-ID: <4761@hplabsz.HPL.HP.COM>
Date: 2 Feb 90 09:46:37 GMT
From: Niels Mayer <hplabsz!mayer@hplabs.hp.com>
To: scheme@mc.lcs.mit.edu
Subject: Re: X bindings in Scheme [long]
>> Actually, what I'd like is Xt (or, even better, Motif) from Scheme. It
>> would be even better to be able to write widgets in Scheme! The problem
>> is that the architecture of Xt involves a lot of callbacks, and,
>> generally (unless you're using the DECWRL compiler) you can't call
>> Scheme from C.
Well it's not quite scheme, but....
WINTERP is similar to Elk, but is based on XLISP. It features XLISP
OOP interface to the Motif widgets; a serverized lisp listener that
handles lisp events and X events simultanously; allows fully
interactive language-based or direct manipulation of widgets. WINTERP
is designed to provide a gnuemacs-like rapid prototyping environment,
and XLISP makes it easy to call LISP-->C or C-->LISP.
The OOP style of widget programming enabled by winterp is quite nifty
as it lets you subclass widgets in Lisp, override methods, or add new
methods. For an example, I've included a simple file-search browser
that is built off of the unix grep(1) and a subclassed Motif list
widget... other other examples include a bitmap browser that sets
your rootmap, a mh-based mail browser, menus, etc.
Get winterp from contrib/clients/winterp on the X11r4 tape-2 (be sure
to get contrib/R4fixes/winterp/patch-0), or get it via anonymous ftp
from expo.lcs.mit.edu directory contrib/winterp; files winterp.tar.Z,
winterp.README. contrib/winterp/winterp.binaries contains binaries
for HP machines.
; -*-Lisp-*-
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;
; File: grep-br.lsp
; RCS: $Header: grep-br.lsp,v 1.1 89/11/25 04:00:19 mayer Exp $
; Description: A transformation of mail-br.lsp into a search browser using the
; unix grep command. Evaluate the form '(grep-browser)' to bring
; up the application.
; Author: Niels Mayer, HPLabs
; Created: Mon Nov 20 18:13:23 1989
; Modified: Sat Nov 25 01:04:49 1989 (Niels Mayer) mayer@hplnpm
; Language: Lisp
; Package: N/A
; Status: X11r4 contrib tape release
;
; (c) Copyright 1989, Hewlett-Packard Company.
;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; Make a subclass of XM_LIST_WIDGET_CLASS which holds an additional
;; instance variable 'items'. 'items' is an array of arbitrary objects
;; (BROWSER_OBJECT) to be displayed in a browser made from the list widget.
;;
;; BROWSER-OBJECT can be any arbitrary xlisp object that responds to
;; the message :display_string.
;;
;; Message :display_string must return a string which is used as the
;; textual representation of the object in the browser display.
;;
(setq List_Browser
(send Class :new
'(items) ;new instance vars
'() ;no class vars
XM_LIST_WIDGET_CLASS)) ;superclass
;;
;; We add a method to set the items browsed by the list browser
;; and set the 'items' instance variable.
;;
;; (send List_Browser :set_browser_items <items_list>)
;; <items_list> is a list of BROWSER_OBJECTs as described above.
;;
(send List_Browser :answer :SET_BROWSER_ITEMS '(items_list)
'(
(let* (
(items_end_idx (length items_list))
(display_items (make-array items_end_idx)))
;; initialize the 'items' instance variable so that it
;; holds all the BROWSER_OBJECTs passed in <items_list>
(setq items (make-array items_end_idx)) ;create the array
(do ( ;copy elts from list to array
(i 0 (1+ i))
(elts items_list (cdr elts)))
;; loop till no more elts
((null elts))
;; loop body
(setf (aref items i) (car elts))
(setf (aref display_items i) (send (car elts) :display_string))
)
;; initialize the widget, passing in the browser items.
(send self :set_values
:xmn_items display_items
:xmn_item_count items_end_idx
)
)
)
)
;;
;; Given a List Widget position, this returns the object associated
;; with that position. Note that the first item is at position 1.
;;
(send List_Browser :answer :GET_ITEM_AT_POSITION '(position)
'(
(aref items (1- position))
))
;;
;; override methods on XM_LIST_WIDGET_CLASS so that they work properly
;; with the list browser. Note that all other list methods work fine
;; on the list browser
;;
(send List_Browser :answer :ADD_ITEM '(item position)
'(
(setq items (array-insert-pos items (1- position) item))
(send-super :add_item (send item :display_string) position)
)
)
(send List_Browser :answer :ADD_ITEM_UNSELECTED '(item position)
'(
(setq items (array-insert-pos items (1- position) item))
(send-super :add_item_unselected (send item :display_string) position)
)
)
(send List_Browser :answer :DELETE_ITEM '(item)
'(
;; this is too lame to implement... requires that we compare
;; item with the result of :display_string done on every element
;; of ivar 'items'
(error "Message :DELETE_ITEM not supported in List_Browser")
)
)
(send List_Browser :answer :DELETE_POS '(position)
'(
(setq items (array-delete-pos items (1- position)))
(send-super :delete_pos position)
)
)
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Define a BROWSER_OBJECT
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; Each BROWSER_OBJECT holds the information summarizing one mail message.
;; the information is split up into individual fields because we may want
;; to be able to sort on one field, or search for mathes on one field.
;;
(setq Grep_Item_Class
(send Class :new
'(file-name line-num match-line)
))
;; this method will read a single line of grep output.
;; and sets the instance variables in the
;; BROWSER_OBJECT to the individual fields of the grep output
(send Grep_Item_Class :answer :read-grep-info '(pipe)
'(
(if (and
(setq file-name (fscanf-string pipe "%[↑:]:"))
(setq line-num (fscanf-fixnum pipe "%d:"))
(setq match-line (fscanf-string pipe "%[↑\n]\n"))
)
self ;return self if succesful
NIL ;return NIL if hit EOF
)
)
)
(send Grep_Item_Class :answer :display_string '()
'(
(format nil "~A: ~A"
file-name match-line)
))
(send Grep_Item_Class :answer :file-name '()
'(
file-name
))
(send Grep_Item_Class :answer :line-num '()
'(
line-num
))
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; This returns a list of Grep_Item_Class instances corresponding
;; to the items matching the search pattern and file list given
;; in argument <grep-arg-string>
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(defun grep (grep-arg-string)
(do*
(;; loop variables, initializers, and increments.
(fp (popen (strcat "grep -n "
grep-arg-string
" /dev/null")
:direction :input))
(line (send (send Grep_Item_Class :new) :read-grep-info fp)
(send (send Grep_Item_Class :new) :read-grep-info fp))
(result '()) ;init to an empty list
)
;; loop test and return
((null line) ; :read-grep-info returns NIL on EOF
(pclose fp)
result ;return list of grep objects.
)
;; loop body
(setq result (nconc result (cons line NIL))) ;append grep-obj to list
)
)
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; The Main program -- note that this doesn't use any global variables, so
;; you can have many grep browsers up all at once without having them
;; interact.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(defun grep-browser()
(let (
top_w paned_w controlpanel_w doit_button_w search_label_w
search_editor_w files_label_w files_editor_w list_w filename_label_w
viewtext_w
)
(setq top_w
(send TOP_LEVEL_SHELL_WIDGET_CLASS :new
:XMN_TITLE "Grep Browser"
:XMN_ICON_NAME "Grep Browser"
))
(setq paned_w
(send XM_PANED_WINDOW_WIDGET_CLASS :new :managed top_w
))
(setq controlpanel_w
(send XM_ROW_COLUMN_WIDGET_CLASS :new :managed paned_w
:XMN_ADJUST_LAST t
:XMN_ORIENTATION :HORIZONTAL
:XMN_PACKING :PACK_TIGHT
:XMN_NUM_COLUMNS 1
))
(setq doit_button_w
(send XM_PUSH_BUTTON_WIDGET_CLASS :new :managed controlpanel_w
:XMN_LABEL_STRING "DO SEARCH"
))
(setq search_label_w
(send XM_LABEL_WIDGET_CLASS :new :managed controlpanel_w
:XMN_LABEL_STRING "Search for string:"
))
(setq search_editor_w
(send XM_TEXT_WIDGET_CLASS :new :managed controlpanel_w
:XMN_EDIT_MODE :SINGLE_LINE_EDIT))
(setq files_label_w
(send XM_LABEL_WIDGET_CLASS :new :managed controlpanel_w
:XMN_LABEL_STRING "From Files:"
))
(setq files_editor_w
(send XM_TEXT_WIDGET_CLASS :new :managed controlpanel_w
:XMN_EDIT_MODE :SINGLE_LINE_EDIT))
(setq list_w
(send List_Browser :new :managed :scrolled "browser" paned_w
:xmn_visible_item_count 20
))
(setq filename_label_w
(send XM_LABEL_WIDGET_CLASS :new :managed "label" paned_w
:xmn_label_string "None"
))
(setq viewtext_w
(send XM_TEXT_WIDGET_CLASS :new :managed :scrolled "view" paned_w
:XMN_EDIT_MODE :MULTI_LINE_EDIT
:XMN_HEIGHT 400
:XMN_EDITABLE nil ;don't allow user to change text.
))
(send top_w :realize)
;;
;; set contraint resources on controlpanel so that paned window
;; doesn't give it resize sashes.
;;
(let (height)
(send controlpanel_w :get_values :xmn_height 'height)
(send controlpanel_w :set_values
:xmn_maximum height
:xmn_minimum height
)
)
;;
;; set contraint resources on label widget so that paned window
;; doesn't give it resize sashes.
;;
(let (height)
(send filename_label_w :get_values :xmn_height 'height)
(send filename_label_w :set_values
:xmn_maximum height
:xmn_minimum height
)
)
;;
;; The doit_button initiates a grep search.
;;
(send doit_button_w :add_callback :XMN_ARM_CALLBACK '()
`(
(send list_w :set_browser_items
(grep (strcat
"'" ;quotify string to protect from shell
(send ,search_editor_w :get_string) ;string to search for
"' "
(send ,files_editor_w :get_string)) ;wildcarded files
))
))
;;
;; set up a callback on the list widget initialized above such that
;; a double click on the browser-item will browse the object.
;;
(send list_w :add_callback :xmn_default_action_callback
'(callback_item_position)
`(
(let*
((browsed-object
(send ,list_w :get_item_at_position callback_item_position))
(filename (send browsed-object :file-name))
(linenum (send browsed-object :line-num))
)
(send ,filename_label_w :set_values :xmn_label_string filename)
(send ,filename_label_w :update_display) ;incase reading file takes long time
(send ,viewtext_w :find_file filename linenum)
))
)
))
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Add a :FIND_FILE method to the Motif Text widget.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(send XM_TEXT_WIDGET_CLASS :answer :FIND_FILE '(filename linenum)
'(
(let*
(;; loc vars
(fp
(open filename :direction :input)
)
inspos
text_line
)
(if (null fp)
(error "Can't open file." filename))
(send self :set_string "") ;clear out old text
(send self :disable_redisplay NIL) ;don't show changes till done
(loop
(if (null (setq text_line (read-line fp)))
(return))
(setq inspos (send self :get_insertion_position))
(send self :replace inspos inspos (strcat text_line "\n"))
)
(send self :scroll linenum) ;make <linenum> be the top of screen
(send self :enable_redisplay) ;now show changes...
(close fp)
)
)
)
------------------------------------------------------------------------------
Niels Mayer -- hplabs!mayer -- mayer@hplabs.hp.com
Human-Computer Interaction Department
Hewlett-Packard Laboratories
Palo Alto, CA.
*
------------------------------
End of Scheme Digest
********************
∂03-Feb-90 2324 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #291
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 3 Feb 90 23:23:54 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA14464; Sun, 4 Feb 90 02:23:18 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Sun, 4 Feb 90 02:22:52 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa28100;
4 Feb 90 2:20 EST
Message-Id: <DIGEST.184.900204.020607.10@MC.LCS.MIT.EDU>
Date: 4 Feb 90 02:06:07 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #291
Scheme Digest #291 4 Feb 90 02:06:07 EST
Today's Topics:
1 message without subject
----------------------------------------------------------------------
Message-ID: <9002031901.aa13845@mintaka.lcs.mit.edu>
Date: Sat, 3 Feb 90 03:14 CST
From: listen@ihlpn.att.com
To: Scheme@lcs.mit.edu
remote execution [uucp job ihlpnA0539 (2/3-3:14:41)]
rmail
command exited with status 1 - denied by unix
------------------------------
End of Scheme Digest
********************
∂05-Feb-90 0038 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #292
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 5 Feb 90 00:38:23 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA04286; Mon, 5 Feb 90 03:37:55 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Mon, 5 Feb 90 03:37:25 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa19908;
5 Feb 90 3:27 EST
Message-Id: <DIGEST.184.900205.025156.14@MC.LCS.MIT.EDU>
Date: 5 Feb 90 02:51:55 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #292
Scheme Digest #292 5 Feb 90 02:51:55 EST
Today's Topics:
Scheme for the Amiga
----------------------------------------------------------------------
Message-ID: <304@fe2o3.UUCP>
Date: 5 Feb 90 04:52:42 GMT
From: Rusty Haddock <fe2o3!rusty@mimsy.umd.edu>
To: scheme@mc.lcs.mit.edu
Subject: Scheme for the Amiga
muenx@heike.informatik.uni-dortmund.de (Holger Muenx) writes:
> Hi!
Hello!
> So my question: Is there any smaller version of MIT-Scheme. If yes: where
> can I get it? Or do you know anyone who tried to port Scheme to an Amiga?
Well, there's XScheme but it has nothing to do with MIT-Scheme.
XScheme is in C and was written by the same person (David Betz) that
wrote XLisp. The XScheme that I've gotten to compile on the Amiga
is version 0.20 and runs fairly well with my '020. I downloaded the
sources from the MIPS Magazine's BBS*. The source is about 700K
(uncompressed) and the Amiga executable is about 90K. The original
source was intended for the Lattice C compiler but I have added some
small changes so that it would compile with Manx 3.6 (sorry, no 5.0
yet). I could make everything ftp-able if you (or anyone else) want.
-Rusty-
* David Betz _may_ be reached at the MIPS Magazine BBS
+1 (603) 882-1599, 2400BAUD, 8-N-1
This BBS also carries the latest versions of XLisp and XScheme.
--
Rusty Haddock o {uunet,att,rutgers}!mimsy.umd.edu!fe2o3!rusty
Laurel, Maryland o "IBM sucks silicon!" -- PC Banana Jr, "Bloom County"
------------------------------
End of Scheme Digest
********************
∂05-Feb-90 2349 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #293
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 5 Feb 90 23:49:38 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA22535; Tue, 6 Feb 90 02:47:26 EST
Received: from lcs.mit.edu (lcs.mit.edu) by zurich.ai.mit.edu; Tue, 6 Feb 90 02:46:43 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa18547;
6 Feb 90 2:32 EST
Message-Id: <DIGEST.184.900206.020038.5@MC.LCS.MIT.EDU>
Date: 6 Feb 90 02:00:37 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #293
Scheme Digest #293 6 Feb 90 02:00:37 EST
Today's Topics:
Scheme for the Amiga
CGOL revisited: A Pratt parser for SIOD (scheme in one defun)
(none)
1 message without subject
----------------------------------------------------------------------
Message-ID: <305@fe2o3.UUCP>
Date: 5 Feb 90 05:26:27 GMT
From: Rusty Haddock <fe2o3!rusty@mimsy.umd.edu>
To: scheme@MC.lcs.mit.edu
Subject: Re: Scheme for the Amiga
In article <304@fe2o3.UUCP> rusty%fe2o3@mimsy.umd.edu (Rusty Haddock) writes:
>... The source is about 700K
>(uncompressed) and the Amiga executable is about 90K.
Oops. That 700K figured in the .o (object files). The sources alone
come to about 450K bytes. Sorry about that.
-Rusty-
--
Rusty Haddock o {uunet,att,rutgers}!mimsy.umd.edu!fe2o3!rusty
Laurel, Maryland o "IBM sucks silicon!" -- PC Banana Jr, "Bloom County"
------------------------------
Message-ID: <9002051741.AA03862@heike.informatik.uni-dortmund.de>
Date: Mon, 5 Feb 90 18:41:57 +0100
From: Holger Muenx <muenx@heike.informatik.uni-dortmund.de>
To: scheme@ai.mit.edu
Hi!
Thanks to all who answered to my request for scheme on the Amiga.
Although there are some implementations for the Amiga or at least simple
to port to the Amiga I decided to write my own scheme.
Now there is the next problem. No question of minor programming
difficulties but a severe implementation decision.
It's about tail recursion. I think there were some discussions about that.
At first, it is possible to implement scheme that tail recursions (means
recursions of iterative nature, needing only a constant amount of memory)
really work without allocating new memory during every recursive application.
In Abelson + Sussman it is said it is possible and I think in MIT-Scheme it
is done.
But HOW can it be done? I think the problem is to determine in every
application of a compound procedure if it is the last command which is evaluated
in a procedure. For example, the following is obviously tail recursive:
(define (dummy x)
(print x)
(dummy (1+ x)))
There it is simple to test if (dummy ...) is the last evaluated expression.
But this example is senseless and in real programming it would never occur.
(define (dummy x)
(if (< x 10)
(dummy (1+ x))
'DONE))
Here you cannot immedeatly see if (dummy ...) is the last evaluated
expression. In some way you have to analyze the meaning of the procedure.
To my opinion it is not enough to test additional in special forms like 'if'
or 'cond' if the application is the last evaluated expression in this form
because after the 'if' or 'cond' clause there can be other expressions to be
evaluated.
Don't know if you see my problem and if there is a simple solution for it.
Today I asked a professsor and a doctor here at UniDo but both couldn't
help me. Thank you for your interest. Ciao,
-Holger
-----------------------------------------------------------------------------
Holger Muenx muenx@heike.informatik.uni-dortmund.de
IRB, UniDo
4600 Dortmund
West-Germany
------------------------------
Message-ID: <9002051925.AA11173@schizo.samsung.com>
Date: Mon, 5 Feb 90 13:04:55 EDT
From: gjc@mitech.com
Reply-To: gjc@mitech.com
To: scheme@lcs.mit.edu
Subject: CGOL revisited: A Pratt parser for SIOD (scheme in one defun)
From time to time people ask me for CGOL, so I've decided to
make the technology more available by consing up something that will
run in SIOD version 2.3 directly, without the need to bootstrap the
thing as with the original CGOL implementation. Please forgive me
if the code looks like Maclisp.
The values for the binding powers are a tricky area, and these are somewhat
like what is documented for Macsyma.
---- START OF PRATT.SCM ----
;; -*-mode:lisp-*-
;;
;; A simple Pratt-Parser for SIOD: 2-FEB-90, George Carrette, GJC@PARADIGM.COM
;;
;; COPYRIGHT (c) 1990 BY
;; PARADIGM ASSOCIATES INCORPORATED, CAMBRIDGE, MASSACHUSETTS.
;; See the source file SLIB.C for more information.
;;
;;
;; Based on a theory of parsing presented in:
;;
;; Pratt, Vaughan R., ``Top Down Operator Precedence,''
;; ACM Symposium on Principles of Programming Languages
;; Boston, MA; October, 1973.
;;
;; The following terms may be useful in deciphering this code:
;; NUD -- NUll left Denotation (op has nothing to its left (prefix))
;; LED -- LEft Denotation (op has something to left (postfix or infix))
;; LBP -- Left Binding Power (the stickiness to the left)
;; RBP -- Right Binding Power (the stickiness to the right)
;;
;;
;; Example calls
;;
;; (pl '(f [ a ] = a + b / c)) => (= (f a) (+ a (/ b c)))
;;
;; (pl '(if g [ a COMMA b ] then a > b else k * c + a * b))
;; => (if (g a b) (> a b) (+ (* k c) (* a b)))
;;
;; Notes:
;;
;; This code must be used with siod.scm loaded, in siod version 2.3
;;
;; For practical use you will want to write some code to
;; break up input into tokens.
(defvar *eof* (list '*eof*))
;;
(defun pl (l)
;; parse a list of tokens
(setq l (append l '($)))
(toplevel-parse (lambda (op arg)
(cond ((eq op 'peek)
(if l (car l) *eof*))
((eq op 'get)
(if l (pop l) *eof*))
((eq op 'unget)
(push arg l))))))
(defun peek-token (stream)
(stream 'peek nil))
(defun read-token (stream)
(stream 'get nil))
(defun unread-token (x stream)
(stream 'unget x))
(defun toplevel-parse (stream)
(if (eq *eof* (peek-token stream))
(read-token stream)
(parse -1 stream)))
(defun get (sym key)
;; symbolconc takes the place of an explicit hash-table
(setq sym (symbolconc sym '+INTERNAL-PLIST))
(and (symbol-bound? sym)
(cdr (assq key (symbol-value sym)))))
(defun putprop (sym val key)
(set-cdr! (let ((cell (symbolconc sym '+INTERNAL-PLIST)))
(or (assq key (if (symbol-bound? cell)
(symbol-value cell)
(set-symbol-value! cell nil)))
(car (set-symbol-value! cell
(cons (list key)
(symbol-value cell))))))
val))
(defun plist (sym)
(setq sym (symbolconc sym '+INTERNAL-PLIST))
(and (symbol-bound? sym)
(symbol-value sym)))
(defun value-if-symbol (x)
(if (symbol? x)
(symbol-value x)
x))
(defun nudcall (token stream)
(if (symbol? token)
(if (get token 'nud)
((value-if-symbol (get token 'nud)) token stream)
(if (get token 'led)
(error 'not-a-prefix-operator token)
token)
token)
token))
(defun ledcall (token left stream)
((value-if-symbol (or (and (symbol? token)
(get token 'led))
(error 'not-an-infix-operator token)))
token
left
stream))
(defun lbp (token)
(or (and (symbol? token) (get token 'lbp))
200))
(defun rbp (token)
(or (and (symbol? token) (get token 'rbp))
200))
(defvar *parse-debug* nil)
(defun parse (rbp-level stream)
(if *parse-debug* (print `(parse ,rbp-level)))
(defun parse-loop (translation)
(if (< rbp-level (lbp (peek-token stream)))
(parse-loop (ledcall (read-token stream) translation stream))
(begin (if *parse-debug* (print translation))
translation)))
(parse-loop (nudcall (read-token stream) stream)))
(defun header (token)
(or (get token 'header) token))
(defun parse-prefix (token stream)
(list (header token)
(parse (rbp token) stream)))
(defun parse-infix (token left stream)
(list (header token)
left
(parse (rbp token) stream)))
(defun parse-nary (token left stream)
(cons (header token) (cons left (prsnary token stream))))
(defun parse-matchfix (token left stream)
(cons (header token)
(prsmatch (or (get token 'match) token)
stream)))
(defun prsnary (token stream)
(defun loop (l)
(if (eq? token (peek-token stream))
(begin (read-token stream)
(loop (cons (parse (rbp token) stream) l)))
(reverse l)))
(loop (list (parse (rbp token) stream))))
(defun prsmatch (token stream)
(if (eq? token (peek-token stream))
(begin (read-token stream)
nil)
(begin (defun loop (l)
(if (eq? token (peek-token stream))
(begin (read-token stream)
(reverse l))
(if (eq? 'COMMA (peek-token stream))
(begin (read-token stream)
(loop (cons (parse 10 stream) l)))
(error 'comma-or-match-not-found (read-token stream)))))
(loop (list (parse 10 stream))))))
(defun delim-err (token stream)
(error 'illegal-use-of-delimiter token))
(defun erb-error (token left stream)
(error 'too-many token))
(defun premterm-err (token stream)
(error 'premature-termination-of-input token))
(defmac (defprops form)
(defun loop (l result)
(if (null? l)
`(begin ,@result)
(loop (cddr l)
`((putprop ',(cadr form) ',(cadr l) ',(car l))
,@result))))
(loop (cddr form) nil))
(defprops $
lbp -1
nud premterm-err)
(defprops COMMA
lbp 10
nud delim-err)
(defprops ]
nud delim-err
led erb-err
lbp 5)
(defprops [
nud open-paren-nud
led open-paren-led
lbp 200)
(defprops if
nud if-nud
rbp 45)
(defprops then
nud delim-err
lbp 5
rbp 25)
(defprops else
nud delim-err
lbp 5
rbp 25)
(defprops -
nud parse-prefix
led parse-nary
lbp 100
rbp 100)
(defprops +
nud parse-prefix
led parse-nary
lbp 100
rbp 100)
(defprops *
led parse-nary
lbp 120)
(defprops =
led parse-infix
lbp 80
rbp 80)
(defprops **
lbp 140
rbp 139
led parse-infix)
(defprops :=
led parse-infix
lbp 80
rbp 80)
(defprops /
led parse-infix
lbp 120
rbp 120)
(defprops >
led parse-infix
lbp 80
rbp 80)
(defprops <
led parse-infix
lbp 80
rbp 80)
(defprops >=
led parse-infix
lbp 80
rbp 80)
(defprops <=
led parse-infix
lbp 80
rbp 80)
(defprops not
nud parse-prefix
lbp 70
rbp 70)
(defprops and
led parse-nary
lbp 65)
(defprops or
led parse-nary
lbp 60)
(defun open-paren-nud (token stream)
(if (eq (peek-token stream) '])
nil
(let ((right (prsmatch '] stream)))
(if (cdr right)
(cons 'sequence right)
(car right)))))
(defun open-paren-led (token left stream)
(cons (header left) (prsmatch '] stream)))
(defun if-nud (token stream)
(define pred (parse (rbp token) stream))
(define then (if (eq? (peek-token stream) 'then)
(parse (rbp (read-token stream)) stream)
(error 'missing-then)))
(if (eq? (peek-token stream) 'else)
`(if ,pred ,then ,(parse (rbp (read-token stream)) stream))
`(if ,pred ,then)))
---- END OF PRATT.SCM ----
------------------------------
Message-ID: <1990Feb5.194739.3018@sun.soe.clarkson.edu>
Date: 5 Feb 90 19:47:39 GMT
From: Jason Coughlin <zaphod.mps.ohio-state.edu!rpi!image.soe.clarkson.edu!jk0@think.com>
To: scheme@mc.lcs.mit.edu
Subject: Re: (none)
muenx@heike.informatik.uni-dortmund.de (Holger Muenx):
> Although there are some implementations for the Amiga or at least simple
> to port to the Amiga I decided to write my own scheme.
>
I could give you source to a beginning of scheme so that you
wouldn't have to implement the WHOLE thing. I am writing a scheme -- and
the interpreter is almost completely finished (I'm acutally working onthe
compiler right now). The source is not public domain but it is freely
distributable -- of course, I'd like your improvements to be freely
distributable too [your problem in the first case!], but we could work
this out.
> At first, it is possible to implement scheme that tail recursions (means
> recursions of iterative nature, needing only a constant amount of memory)
> really work without allocating new memory during every recursive application.
> In Abelson + Sussman it is said it is possible and I think in MIT-Scheme it
> is done.
>
Correct, the stack doesn't grow by 1 cons node. I have a compile
time option that lets you see this (the stack really doesn't grow at all).
> Here you cannot immedeatly see if (dummy ...) is the last evaluated
> expression. In some way you have to analyze the meaning of the procedure.
> To my opinion it is not enough to test additional in special forms like 'if'
> or 'cond' if the application is the last evaluated expression in this form
> because after the 'if' or 'cond' clause there can be other expressions to be
> evaluated.
>
You're thinking on too high a level -- human level. it isn't
implemented this way.
> But HOW can it be done? I think the problem is to determine in every
> application of a compound procedure if it is the last command which is evaluated
> in a procedure. For example, the following is obviously tail recursive:
>
> (define (dummy x)
> (print x)
> (dummy (1+ x)))
>
first of all, this is equivalent to (and the interp probably sees it
like this):
(define dummy
(lambda (x)
(print x)
(dummy (+ 1 x))
)
)
lambda is a special form that returns a closure. a closure is
code and it's associated env (remember static scope -- things are evaled
in the env in which they're defined). it probably looks like this:
(*CLOSURE* parms body env) where *CLOSURE* is just a symbol and env is
the CURRENT env.
Ok, the interpreter is a stack based machine. To evaluate the
closure (NOT LAMBDA, you've got to separate the eval of LAMBDA and what
it returns [a closure]). On entering the closure (that's what dummy is)
Since it's static scope, you:
(1) push the current env on the stack (so you can return to it
when you're done with the closure)
(2) restore the env from the closure (static scope, evaluate something
in the environment in which it is DEFINED )
(3) bind args to parms over this new environment
(4) evaluate code in closure (by pushing the body of the closure
on the stack)
(5) restore environment that you pushed on the stack
that handles one evaluation.
if your language doesn't handle tail recursion, then it does this ad
nauseum. at each invokation of the closure, it pushes the current
environment so your stack has ALL of these environments on it -- the
tail recurision comes in because when you're done, you have to step back
through ALL of those environments. to handle tail recursion, change
step 1.
(1) if there is an environemnt on the stack, skip to step 2. if
not, push the current env
this way, there is only 1 env on the stack during any directly
recursive call. viola, no tail recursion (you immediately pop back to
the original environment because that's the only one on the stack).
--
Jason Coughlin ( jk0@sun.soe.clarkson.edu , jk0@clutx )
"Every jumbled pile of person has a thinking part that wonders what the
part that isn't thinking isn't thinking of." - They Might Be Giants
------------------------------
End of Scheme Digest
********************
∂07-Feb-90 0030 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #294
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 7 Feb 90 00:30:02 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA09852; Wed, 7 Feb 90 03:28:57 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Wed, 7 Feb 90 03:28:24 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa14293;
7 Feb 90 3:21 EST
Message-Id: <DIGEST.184.900207.030040.12@MC.LCS.MIT.EDU>
Date: 7 Feb 90 03:00:40 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #294
Scheme Digest #294 7 Feb 90 03:00:40 EST
Today's Topics:
OOP with Scheme?
Scheme Digest #293
Scheme compiler in scheme ?
XScheme 0.20 for the Amiga available on UUNET
Pc scheme where?
----------------------------------------------------------------------
Message-ID: <9002061437.AA17563@gmdzi.UUCP>
Date: Tue, 6 Feb 90 15:37:53 -0100
From: Harry Bretthauer <gmdzi!bretth@uunet.uu.net>
To: Scheme@mc.lcs.mit.edu
CC: gmdzi!?@uunet.uu.net
Subject: OOP with Scheme?
I'm currently working on a conversion of an object oriented extension for
Common Lisp (MetaClassSystem by Harry Bretthauer and Juergen Kopp at the
"Gesellschaft fuer Mathematik und Datenverarbeitung", GMD) to Scheme
(particularly MacScheme and PCScheme).
Now I would like to know which OOP-Extensions for Scheme exist until now or
are under development.
If anybody has experiences with OOP in Scheme or has a good overview
in this area, I would be happy for an answer in this mailing group.
Andreas Lange
------------------------------
Message-ID: <9002061810.AA03161@ungar.think.com>
Date: Tue, 6 Feb 90 13:10:51 EST
From: Guy Steele <gls@think.com>
To: muenx@heike.informatik.uni-dortmund.de
CC: Scheme@lcs.mit.edu
Subject: Scheme Digest #293
But HOW can it be done? I think the problem is to determine in every
application of a compound procedure if it is the last command which is evaluated
in a procedure.
Another point of view is that the problem is to construct a framework in
which application does not require conditional treatment. This can be
done. The idea is that a procedure call *never* adds anything to the
stack; *all* calls, as such, are tail-recursive. However, not all
*evaluations* are tail-recursive. A frame must be added to the stack
whenever one is about to evaluate a function argument, or the predicate
part of a conditional, or any form except the last in a block, or in
general whenever one is about to evaluate a subform but must regain
control again.
For a more extensive treatment of this topic, see my paper "Procedure Call
Implementations Considered Harmful" in the Proceedings of the 1977 ACM
National Conference.
Happy hacking!
--Guy Steele
------------------------------
Message-ID: <2530001@hpgnd.HP.COM>
Date: 5 Feb 90 16:16:36 GMT
From: Jean-Michel ROSSET <hp-ses!hpbbn!hpgnd!jmrosset@hplabs.hp.com>
To: scheme@MC.lcs.mit.edu
Subject: Scheme compiler in scheme ?
I have xscheme on a 68000 based machine (namely an atari) and I would like
to be able to generate efficient code. I guess a scheme compiler in scheme
could do it. Is there anything available and compatible with the memory
limitations of this kind of machine (a couple of Mbytes and no virtual memory)?
If my quest was infortunate, what is the bibliography startup for implementing
one?
Thanks
Jean-Michel ROSSET
jm@hpgnd.hp.com
..My opinions are shared
------------------------------
Message-ID: <307@fe2o3.UUCP>
Date: 6 Feb 90 20:51:58 GMT
From: Rusty Haddock <fe2o3!rusty@mimsy.umd.edu>
To: scheme@mc.lcs.mit.edu
Subject: XScheme 0.20 for the Amiga available on UUNET
This morning (2/6) I put a Zoo file containing the sources, two
binaries, and documentation for David Betz's XScheme 0.20 (yes, not
even 1.0 yet) with my Amiga/Manx modifications onto UUNET.UU.NET
(192.48.96.2) for anonymous ftp. The file was
amiga-sources/xscheme.20.zoo
The two binaries included, xscheme and xscheme.881, were compiled
for using the IEEE math libraries and 68881/2 inline code, respectfully.
Two things to remember:
1) Use binary mode for ftp'ing.
2) I simply ftp'ed this onto UUNET's disks without any
specific permission to do so. As such, my file may
disappear without warning. If this happens I'll find
another way to keep this ftp'able.
Enjoy!
-Rusty-
--
Rusty Haddock o {uunet,att,rutgers}!mimsy.umd.edu!fe2o3!rusty
Laurel, Maryland o "IBM sucks silicon!" -- PC Banana Jr, "Bloom County"
------------------------------
Message-ID: <4148@jhunix.HCF.JHU.EDU>
Date: 6 Feb 90 23:07:01 GMT
From: Speed <snorkelwacker!usc!samsung!aplcen!jhunix!ins_ajdc@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Pc scheme where?
Hi!
I've just started reading this group (obviously), and have seen several
people mention PC scheme. Where could I get a copy? I have ftp, and the like.
Secondly is this compatable with scheme 7.0? I currently have a class on
scheme and we need 7.0.0 beta. I have tried to work with the original code,
but it was a quite large task. Please respond by E-mail.
Thanx in advance,
-- Justin
ins_ajdc@jhunix.hcf.jhu.edu
------------------------------
End of Scheme Digest
********************
∂08-Feb-90 0021 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #295
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 8 Feb 90 00:21:31 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA29280; Thu, 8 Feb 90 03:18:39 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Thu, 8 Feb 90 03:18:10 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa12220;
8 Feb 90 3:01 EST
Message-Id: <DIGEST.184.900208.024543.17@MC.LCS.MIT.EDU>
Date: 8 Feb 90 02:45:42 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #295
Scheme Digest #295 8 Feb 90 02:45:42 EST
Today's Topics:
(none) (2 messages)
----------------------------------------------------------------------
Message-ID: <SIMON.90Feb7120454@viking.cs.tu-berlin.de>
Date: 7 Feb 90 11:04:54 GMT
From: Simon Leinen <eru!luth!sunic!mcsun!unido!tub!tubopal!opal!simon@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: (none)
In article <9002051741.AA03862@heike.informatik.uni-dortmund.de> muenx@heike.informatik.uni-dortmund.de (Holger Muenx) writes:
(define (dummy x)
(if (< x 10)
(dummy (1+ x))
'DONE))
Here you cannot immediately see if (dummy ...) is the last
evaluated expression. In some way you have to analyze the meaning
of the procedure.
What you have is almost THE CLASSICAL EXAMPLE of tail recursion. A
function call is a tail call if it occurs last *in an execution path*
of the calling function, and this is the case for the call to `dummy'.
In the example, the if form is known to be the last form in the
function body. Either the `then' or the `else' branch is taken. The
else branch just returns a constant, which cannot be optimized very
much. The then part calls a function and returns the result of this
call. Call and return can be transformed into a jump, and the jump
can be transformed into a branch, since the called function is the
same as the calling function. Thus the tail-recursive call can be
eliminated, and this is what you can expect from any decent Lisp or
Scheme compiler.
To my opinion it is not enough to test additional in special
forms like 'if' or 'cond' if the application is the last
evaluated expression in this form because after the 'if' or
'cond' clause there can be other expressions to be evaluated.
If there were other forms after the if, you could only optimize
tail-recursion in those forms. Tail calls only occur at the end of a
sequence (hence the word `tail').
This is why Lisp (or Scheme) programmers change a definition like
(define fac (lambda (n)
(if (= n 0)
1
(* n (fac (- n 1)))))) ; tail-call to *, but not to fac
into the less obvious, but more efficient
(define fac (lambda (n)
(letrec ((fac-aux (lambda (n acc)
(if (= n 0)
acc
(fac-aux (- n 1) (* n acc)))))) ; tail-call to fac-aux
(fac-aux n 1))))
Unfortunately, most existing compilers don't perform this optimization
themselves.
Today I asked a professsor and a doctor here at UniDo but both
couldn't help me.
Don't expect any professor in this country to be able to help you.
Lisp wird in Deutschland einfach nicht ernstgenommen.
Viele Gruesse und happy LISPing,
--
Simon Leinen.
------------------------------
Message-ID: <4782@brazos.Rice.edu>
Date: 7 Feb 90 23:00:08 GMT
From: Dorai Sitaram <titan!dorai@rice.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: (none)
In article <SIMON.90Feb7120454@viking.cs.tu-berlin.de> simon@opal.tu-berlin.de (Simon Leinen) writes:
$In article <9002051741.AA03862@heike.informatik.uni-dortmund.de> muenx@heike.informatik.uni-dortmund.de (Holger Muenx) writes:
$This is why Lisp (or Scheme) programmers change a definition like
$
$ (define fac (lambda (n)
$ (if (= n 0)
$ 1
$ (* n (fac (- n 1)))))) ; tail-call to *, but not to fac
$
$into the less obvious, but more efficient
$
$ (define fac (lambda (n)
$ (letrec ((fac-aux (lambda (n acc)
$ (if (= n 0)
$ acc
$ (fac-aux (- n 1) (* n acc)))))) ; tail-call to fac-aux
$ (fac-aux n 1))))
$
$Unfortunately, most existing compilers don't perform this optimization
$themselves.
"Unfortunately"? I wouldn't want the compiler to perform this
optimization, for if you unwind the *-calls, you'll find the
non-tail-rec version does (* n (* n-1 (* n-2 ... 1))), while the
tail-rec one does (* 1 (* 2 (* 3 ... (* n 1)))). The optimization
hinges too much on the commutativity of * for my comfort.
$ Today I asked a professsor and a doctor here at UniDo but both
$ couldn't help me.
$
$Don't expect any professor in this country to be able to help you.
$Lisp wird in Deutschland einfach nicht ernstgenommen.
(I guess you mean Scheme rather than Lisp, since none of the (other)
Lisps bother even about tail-call optimization, not to speak of the
optimizations that Holger and you speak of.)
I thought Elk was Made in Germany. So schlimm kann es doch nicht
sein.
$Viele Gruesse und happy LISPing,
--dorai
--
------------------------------------------------------------------------------
It may be that the gulfs will wash us down;
It may be we shall touch the Happy Isles.
------------------------------------------------------------------------------
------------------------------
End of Scheme Digest
********************
∂09-Feb-90 0016 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #296
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 9 Feb 90 00:16:06 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA19818; Fri, 9 Feb 90 03:14:08 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Fri, 9 Feb 90 03:13:34 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa06337;
9 Feb 90 2:41 EST
Message-Id: <DIGEST.184.900209.021604.23@MC.LCS.MIT.EDU>
Date: 9 Feb 90 02:16:04 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #296
Scheme Digest #296 9 Feb 90 02:16:04 EST
Today's Topics:
(none) (3 messages)
Scheme Digest #295
X bindings in Scheme? (3 messages)
MIT-Scheme documentaion question
----------------------------------------------------------------------
Message-ID: <9002081400.AA15746@zurich.ai.mit.edu>
Date: Thu, 8 Feb 90 09:00:43 est
From: "Guillermo J. Rozas" <jinx@zurich.ai.mit.edu>
Reply-To: jinx@zurich.ai.mit.edu
To: titan!dorai@rice.edu
CC: scheme@mc.lcs.mit.edu
Subject: (none)
"Unfortunately"? I wouldn't want the compiler to perform this
optimization, for if you unwind the *-calls, you'll find the
non-tail-rec version does (* n (* n-1 (* n-2 ... 1))), while the
tail-rec one does (* 1 (* 2 (* 3 ... (* n 1)))). The optimization
hinges too much on the commutativity of * for my comfort.
Commutativity should not be a problem as long as the compiler can
determine that * is really *. A worse problem is associativity, which
doesn't generally hold for computer arithmetic, although it typically
holds in Lisp systems when restricted to integers.
(I guess you mean Scheme rather than Lisp, since none of the (other)
Lisps bother even about tail-call optimization, not to speak of the
optimizations that Holger and you speak of.)
If I'm not mistaken, the MacLisp compiler handled some purely local
cases of tail-call optimization, and the Lucid compiler handles even
more. The difference is that Scheme requires that the language be
properly tail recursive, that is, calls in tail position (whether to a
procedure visible at "compile" time or not) should generate no net
growth of storage.
For example, the following contrived program should be an infinite
loop (no net growth of storage) when given a list with a single
element as an argument, yet it is an infinite recursion when given a
longer list.
(define (tst l)
(define (flat-apply f original)
(define (flatten-1 l add-to-what)
(if (pair? l)
(flatten-1 (car l) (flatten-2 (cdr l) add-to-what))
(f l add-to-what)))
(define (flatten-2 l add-to-what)
(cond ((pair? l) (flatten-1 (car l) (flatten-2 (cdr l) add-to-what)))
((null? l) add-to-what)
(else (error "Flatten: Bad list" original))))
(flatten-2 original '()))
(define (test-f element ignore)
(newline)
(write element)
(flat-apply test-f l))
(flat-apply test-f l))
------------------------------
Message-ID: <9002081522.AA24765@tub.UUCP>
Date: Thu, 8 Feb 90 16:22:57 +0100
From: Oliver Laumann <net%TUB.BITNET@mitvma.mit.edu>
To: Scheme@lcs.mit.edu
Subject: Re: (none)
> $Don't expect any professor in this country to be able to help you.
>
> I thought Elk was Made in Germany. So schlimm kann es doch nicht sein.
I wrote Elk without any professor's help; in fact, the only useful help
I was able to get was from the participants of the Scheme mailing list!
Regards,
--
Oliver Laumann net@TUB.BITNET net@tub.cs.tu-berlin.de net@tub.UUCP
------------------------------
Message-ID: <9002081548.AA10809@ungar.think.com>
Date: Thu, 8 Feb 90 10:48:56 EST
From: Guy Steele <gls@think.com>
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #295
Date: 7 Feb 90 23:00:08 GMT
From: Dorai Sitaram <titan!dorai@rice.edu>
... simon@opal.tu-berlin.de (Simon Leinen) writes:
$... muenx@heike.informatik.uni-dortmund.de (Holger Muenx) writes:
$This is why Lisp (or Scheme) programmers change a definition like
$
$ (define fac (lambda (n)
$ (if (= n 0)
$ 1
$ (* n (fac (- n 1)))))) ; tail-call to *, but not to fac
$
$into the less obvious, but more efficient
$
$ (define fac (lambda (n)
$ (letrec ((fac-aux (lambda (n acc)
$ (if (= n 0)
$ acc
$ (fac-aux (- n 1) (* n acc)))))) ; tail-call to fac-aux
$ (fac-aux n 1))))
$
$Unfortunately, most existing compilers don't perform this optimization
$themselves.
"Unfortunately"? I wouldn't want the compiler to perform this
optimization, for if you unwind the *-calls, you'll find the
non-tail-rec version does (* n (* n-1 (* n-2 ... 1))), while the
tail-rec one does (* 1 (* 2 (* 3 ... (* n 1)))). The optimization
hinges too much on the commutativity of * for my comfort.
Indeed, you do need to know that * is associative (commutativity
is not required).
See Darlington and Burstall. "A Transformation System for Developing
Recursive Programs", Journal of the ACM, January 1977, and a pile
of other papers that it inspired.
--Guy Steele
------------------------------
Message-ID: <2891@draken.nada.kth.se>
Date: 8 Feb 90 18:26:41 GMT
From: H}kan Huss <eru!luth!sunic!draken!huss@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: X bindings in Scheme?
rather easy. Some systems also provide interfaces to the toolkit
layers of X. In our opinion, however, the main question is not
the feasibility, but rather the desirability of this approach. We
believe that the C interface is not suited for direct use from Scheme.
To support this notion we have designed an interface between Scheme
and X called SCIX, written entirely in Scheme. What we wanted to
achieve with this system was a model of the X window system that more
closely matched the means of abstraction available in Scheme. I.e,
a model that is object-oriented from the bottom and up. We have
found that this approach makes widget construction simple and elegant.
The price of elegance is, as always, performance. Run interactively
the system is rather inefficient. Thus, in order for it to be interesting
one needs a compiling Scheme system. Our implementation is based on
the WRL Scheme->C system.
SCIX has been developed for Digital Equipment, but it is meant to be
made freely available. It is scheduled to be released in March.
Regards,
Hakan Huss Johan Ihren
<huss@nada.kth.se> <johani@nada.kth.se>
------------------------------
Message-ID: <2892@draken.nada.kth.se>
Date: 8 Feb 90 18:33:06 GMT
From: H}kan Huss <eru!luth!sunic!draken!huss@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: X bindings in Scheme?
Sorry, the first line of the previous post got mangled. It should have
read:
To interface Scheme to Xlib is, as several people have reported,
rather easy...
------------------------------
Message-ID: <2008@osc.COM>
Date: 7 Feb 90 21:36:48 GMT
From: Joe Keane <voder!nsc!amdahl!pacbell!osc!jgk@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: (none)
In article <9002051741.AA03862@heike.informatik.uni-dortmund.de>
muenx@heike.informatik.uni-dortmund.de (Holger Muenx) writes:
>At first, it is possible to implement scheme that tail recursions (means
>recursions of iterative nature, needing only a constant amount of memory)
>really work without allocating new memory during every recursive application.
>In Abelson + Sussman it is said it is possible and I think in MIT-Scheme it
>is done.
Wait, isn't this _required_ of an implementation?
------------------------------
Message-ID: <4803@hplabsz.HPL.HP.COM>
Date: 9 Feb 90 03:07:10 GMT
From: Niels Mayer <hplabsz!mayer@hplabs.hp.com>
To: scheme@mc.lcs.mit.edu
Subject: Re: X bindings in Scheme?
In article <2891@draken.nada.kth.se> huss@nada.kth.se (H}kan Huss) writes:
>rather easy. Some systems also provide interfaces to the toolkit
>layers of X. In our opinion, however, the main question is not
>the feasibility, but rather the desirability of this approach. We
>believe that the C interface is not suited for direct use from Scheme.
I agree that the xlib layer is too low-level for lisp programming ...
that's why I like my UI components implemented in C. I've found
WINTERP to be plenty fast -- As long as I'm not forcing XLISP to
perform lots of grinding and garbage generating operations. THose
should be written in C. I may prototype low level routines in XLISP,
but the ones that matter end up in C. IMHO, hybrid programming is the
way to go.
So H}kan, are saying that the compiling scheme system is fast enough?
I guess I need to read Bartlett's paper...
------------------------------------------------------------------------------
Niels Mayer -- hplabs!mayer -- mayer@hplabs.hp.com
Human-Computer Interaction Department
Hewlett-Packard Laboratories
Palo Alto, CA.
*
------------------------------
Message-ID: <16@fanaraaken.stanford.edu>
Date: 9 Feb 90 05:16:59 GMT
From: "James S. Vera" <shelby!vera%fanaraaken.Stanford.EDU@decwrl.dec.com>
To: scheme@mc.lcs.mit.edu
Subject: MIT-Scheme documentaion question
I just pulled MIT-Scheme Release 7 off of gatekeeper and was
disappointed to discover that the accompanied manual has several large
gaps, namely large(?) chunks of sections 8 (OS Features), 9 (Syntax
Transducers), 10 (User Interface) and all of section 11 (Debugging
Tools).
My question is basicly "What's Up?", to which I see a number of
possible answers:
1) "Its public domain software and you shuld be grateful for any
manual at all." (and I am, don't get me wrong)
2) "You obvious don't know TeX from a hole in the Sendmail, try
printing it the _right_ way." (hints?)
3) "These sections weren't written a first but are now available from
blah."
and
4) "These sections aren't written yet, but will be Real Soon Now"
Call now! [$2.00 plus toll if any]
James S. Vera | Internet |Standard Disclaimers
Stanford University|vera@fanaraaken.stanford.edu|Blah Blah Blah Blah
Bellcore |vera2@rigel.cc.bellcore.com |vvv My Cutesy Quote vvv
"When I was young it seemed that life was so wonderful..." - Supertramp
------------------------------
End of Scheme Digest
********************
∂09-Feb-90 2358 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #297
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 9 Feb 90 23:58:51 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA08318; Sat, 10 Feb 90 02:52:00 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Sat, 10 Feb 90 02:51:30 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa23901;
10 Feb 90 2:28 EST
Message-Id: <DIGEST.184.900210.020105.28@MC.LCS.MIT.EDU>
Date: 10 Feb 90 02:01:05 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #297
Scheme Digest #297 10 Feb 90 02:01:05 EST
Today's Topics:
MIT-Scheme documentaion question
(none)
----------------------------------------------------------------------
Message-ID: <9002091653.AA27665@zurich.ai.mit.edu>
Date: Fri, 9 Feb 90 11:53:05 est
From: Chris Hanson <cph@zurich.ai.mit.edu>
To: shelby!vera%fanaraaken.Stanford.EDU@decwrl.dec.com
CC: scheme@mc.lcs.mit.edu
Subject: MIT-Scheme documentaion question
Date: 9 Feb 90 05:16:59 GMT
From: "James S. Vera" <shelby!vera%fanaraaken.Stanford.EDU@decwrl.dec.com>
I just pulled MIT-Scheme Release 7 off of gatekeeper and was
disappointed to discover that the accompanied manual has several large
gaps, namely large(?) chunks of sections 8 (OS Features), 9 (Syntax
Transducers), 10 (User Interface) and all of section 11 (Debugging
Tools).
My question is basicly "What's Up?", to which I see a number of
possible answers:
4) "These sections aren't written yet, but will be Real Soon Now"
This is the correct answer, for some value of RSN. I created those
sections of the manual when I was working on it as an outline for what
remained to be done, but then I ran out of steam long before the thing
was finished.
I don't expect to resume writing that manual any time soon.
------------------------------
Message-ID: <109911@ti-csl.csc.ti.com>
Date: 9 Feb 90 18:56:47 GMT
From: John Gateley <sun-barr!newstop!texsun!smunews!ti-csl!m2!gateley@AMES.ARC.NASA.GOV>
To: scheme@mc.lcs.mit.edu
Subject: Re: (none)
In article <4782@brazos.Rice.edu> dorai@titan.rice.edu (Dorai Sitaram) writes:
<In article <SIMON.90Feb7120454@viking.cs.tu-berlin.de> simon@opal.tu-berlin.de (Simon Leinen) writes:
<$[Transforms fact into tail recursive form]
<$Unfortunately, most existing compilers don't perform this optimization
<$themselves.
<
<"Unfortunately"? I wouldn't want the compiler to perform this
<optimization, for if you unwind the *-calls, you'll find the
<non-tail-rec version does (* n (* n-1 (* n-2 ... 1))), while the
<tail-rec one does (* 1 (* 2 (* 3 ... (* n 1)))). The optimization
<hinges too much on the commutativity of * for my comfort.
This "optimization" can be a pessimization under certain circumstances:
when calling fact on a large number: By doing the multiplications in
reverse order, you spend more time the bignum arithmatic than is made
up by the loop overhead.
<(I guess you mean Scheme rather than Lisp, since none of the (other)
<Lisps bother even about tail-call optimization, not to speak of the
<optimizations that Holger and you speak of.)
While Scheme is the only Lisp I know of that requires tail-recursion,
other dialects of Lisp may provide it: the TI Explorer Common Lisp
compiler is one that does. I believe that Gnu's C compiler also does tail
recursion!
John
gateley@m2.csc.ti.com
------------------------------
End of Scheme Digest
********************
∂11-Feb-90 0040 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #298
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 11 Feb 90 00:40:29 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA18054; Sun, 11 Feb 90 03:34:25 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Sun, 11 Feb 90 03:33:49 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa08047;
11 Feb 90 3:23 EST
Message-Id: <DIGEST.184.900211.030106.31@MC.LCS.MIT.EDU>
Date: 11 Feb 90 03:01:05 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #298
Scheme Digest #298 11 Feb 90 03:01:05 EST
Today's Topics:
optimising factorial
----------------------------------------------------------------------
Message-ID: <2155@syma.sussex.ac.uk>
Date: 10 Feb 90 10:14:55 GMT
From: Aaron Sloman <mcsun!ukc!icdoc!syma!aarons@uunet.uu.net>
To: scheme@mc.lcs.mit.edu
Subject: optimising factorial
dorai@titan.rice.edu (Dorai Sitaram) writes:
(about optimising a recursive defintion of factorial)
>
> ....I wouldn't want the compiler to perform this
> optimization, for if you unwind the *-calls, you'll find the
> non-tail-rec version does (* n (* n-1 (* n-2 ... 1))), while the
> tail-rec one does (* 1 (* 2 (* 3 ... (* n 1)))). The optimization
> hinges too much on the commutativity of * for my comfort.
>
This can be surprisingly important if at some point "big" integers
are created (e.g. factorial 1000). If you start the multiplication
from the top down i.e. (* 1 (* 2 (* 3 ... (* n 1)))) then more big
integers are created than if it is done the other way,
(* n (* n-1 (* n-2 ... 1)))
Unless your compiler is clever about re-using temporary results of
mutiplications etc, the former can spend significantly more time in
garbage collection.
Aaron Sloman,
School of Cognitive and Computing Sciences,
Univ of Sussex, Brighton, BN1 9QH, England
EMAIL aarons@cogs.sussex.ac.uk
aarons%uk.ac.sussex.cogs@nsfnet-relay.ac.uk
------------------------------
End of Scheme Digest
********************
∂13-Feb-90 0055 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #299
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 13 Feb 90 00:55:06 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA09126; Tue, 13 Feb 90 03:53:54 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Tue, 13 Feb 90 03:53:02 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa09241;
13 Feb 90 3:17 EST
Message-Id: <DIGEST.184.900213.023124.40@MC.LCS.MIT.EDU>
Date: 13 Feb 90 02:31:24 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #299
Scheme Digest #299 13 Feb 90 02:31:24 EST
Today's Topics:
Compiling CSCHEME in VMS
quasiquote
NEED: Old SCHEME for 512K Macintosh
Need monochrome PC SCHEME graphics
----------------------------------------------------------------------
Message-ID: <163*FIBCLS05@CLRS.LSI.UPC.ES>
Date: 12 Feb 90 9:38 +0100
From: Javier Bejar Alonso <FIBCLS05@clrs.lsi.upc.es>
To: info-cscheme@zurich.ai.mit.edu, scheme@ai.mit.edu
Subject: Compiling CSCHEME in VMS
We have the sources of CSCHEME 7.0 (MIT-scheme), but we don't have
the '.COM' files to build the 'VMS' version. Could anyone send us
these files via e-mail? (Specially MAKE.COM & SCHEME.COM).
My net address is FIBCLS05@CLRS.LSI.FIB.ES
A question more, are there any troubles to install CSCHEME 7.0 on
VAX VMS 5.1?
Thanks in advance.
JAVIER
P.S. Forgive my bad english.
------------------------------
Message-ID: <1990Feb12.193358.29510@sun.soe.clarkson.edu>
Date: 12 Feb 90 19:33:58 GMT
From: Jason Coughlin <image.soe.clarkson.edu!jk0@uunet.uu.net>
To: scheme@mc.lcs.mit.edu
Subject: quasiquote
Can quasiquote be implemented as an extend-syntax form? If so, does
someone have a definition of it as an extend-syntax form? I'm not
looking for a full blown implementation with recursive quasiquotation
(unless you've got it :-) -- just something that handles cases similar
to these:
`(a b (,(+ 2 3) c) d)
`(a b ,(reverse '(c d e)) f g)
`(a b ,@(reverse '(c d e)) f g)
--
Jason Coughlin ( jk0@sun.soe.clarkson.edu , jk0@clutx )
"Every jumbled pile of person has a thinking part that wonders what the
part that isn't thinking isn't thinking of." - They Might Be Giants
------------------------------
Message-ID: <9002130533.AA16082@vis.>
Date: Mon, 12 Feb 90 21:33:41 -0800
From: vis!greg@ucsd.edu
To: scheme@zurich.ai.mit.edu
Subject: NEED: Old SCHEME for 512K Macintosh
Dear schemers,
I have recommended SCHEME to a friend and student. She has an old
512K Mac. Unfortunately, the current versions of scheme are too large
for her Mac. She can't afford to upgrade right now, so I'm looking
for an old version of MacSCHEME or SCHEME Express or something else
that is lean enough to fit. I understand that older versions of the
products I've mentioned will work just fine. She would be happy to
buy someone's old version. Please send me any information you have
that might be helpful.
Thanks,
_Greg
J. Greg Davidson Virtual Infinity Systems
+1 (619) 452-8059 6231 Branting St; San Diego, CA 92122 USA
greg@vis.com ucbvax--| telesoft--|
vis!greg@nosc.mil decvax--+---ucsd----+--vis
vis!greg@ucsd.edu ihnp4--| nosc----|
------------------------------
Message-ID: <9002130536.AA16090@vis.>
Date: Mon, 12 Feb 90 21:36:56 -0800
From: vis!greg@ucsd.edu
To: scheme@zurich.ai.mit.edu
Subject: Need monochrome PC SCHEME graphics
Dear schemers,
I recommended PC scheme from TI to a friend for her PC. She really
likes it, but can't use it for graphics since it only supports color
graphics. Do you know of any packages for PC scheme, or any other
scheme for the PC which will support monochrome graphics? Any leads
would be much appreciated.
Thanks,
_Greg
J. Greg Davidson Virtual Infinity Systems
+1 (619) 452-8059 6231 Branting St; San Diego, CA 92122 USA
greg@vis.com ucbvax--| telesoft--|
vis!greg@nosc.mil decvax--+---ucsd----+--vis
vis!greg@ucsd.edu ihnp4--| nosc----|
------------------------------
End of Scheme Digest
********************
∂14-Feb-90 0014 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #300
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 14 Feb 90 00:14:06 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA28994; Wed, 14 Feb 90 03:12:35 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Wed, 14 Feb 90 03:11:36 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa26596;
14 Feb 90 2:42 EST
Message-Id: <DIGEST.184.900214.021626.45@MC.LCS.MIT.EDU>
Date: 14 Feb 90 02:16:26 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #300
Scheme Digest #300 14 Feb 90 02:16:26 EST
Today's Topics:
Compiling CSCHEME in VMS
X bindings in Scheme?
----------------------------------------------------------------------
Message-ID: <168*FIBCLS05@CLRS.LSI.UPC.ES>
Date: 13 Feb 90 9:12 +0100
From: Javier Bejar Alonso <FIBCLS05@clrs.lsi.upc.es>
To: scheme@lcs.mit.edu
Subject: Compiling CSCHEME in VMS
We have the sources of CSCHEME 7.0 (MIT-scheme), but we don't have
the '.COM' files to build the 'VMS' version. Could anyone send us
these files via e-mail? (Specially MAKE.COM & SCHEME.COM).
My net address is FIBCLS05@CLRS.LSI.UPC.ES
A question more, are there any troubles to install CSCHEME 7.0 on
VAX VMS 5.1?
Thanks in advance.
JAVIER
P.S. Forgive my bad english.
------------------------------
Message-ID: <2940@draken.nada.kth.se>
Date: 14 Feb 90 01:35:11 GMT
From: Johan Ihren <eru!luth!sunic!draken!johani@bloom-beacon.mit.edu>
To: scheme@MC.lcs.mit.edu
Subject: Re: X bindings in Scheme?
We apologize for not replying earlier. We are in the middle of a period of
exams right now...
In article <4803@hplabsz.HPL.HP.COM>, mayer@hplabsz.HPL.HP.COM (Niels Mayer) writes:
>
> should be written in C. I may prototype low level routines in XLISP,
> but the ones that matter end up in C. IMHO, hybrid programming is the
> way to go.
Of course it has to be hybrid programming, as Scheme does not have any
primitives for interprocess communication ;-) The question is on which level
the conversion between C and Scheme structures should occur, provided that
one wants to be able to manipulate the data as standard Scheme objects. In our
system it is done at a very low level. This enables us to have an environment
much more suited for Scheme.
We are not saying that our approach is the right one, but rather that there
is use for both the WINTERP and the SCIX solutions to the problem.
> So H}kan, are saying that the compiling scheme system is fast enough?
> I guess I need to read Bartlett's paper...
Yes, it is fast enough to be useful. The speed of SCIX is roughly equivalent
to that of CLX (a well known binding to Common Lisp). We haven't done any
formal benchmarks, this is based on elementary comparision of a few example
applications. The main difference between CLX and SCIX is that CLX is an
imperative interface on which object oriented layers (CLUE) can be/has been
added. SCIX is thoroughly object oriented from the inside and out. A SCIX
application runs between four and six times slower than the C equivalent.
This can be disastrous for an application that mostly consists of a speedy
user interface, but is not unusable in other situations. We also have ideas
that will hopefully speed up the eventhandling considerably in the future ;-)
The big problem with the C binding to X is that C isn't really suited to the
task of modelling a window system. The result is a very large system that
is used in different ways on different levels (Xlib vs the toolkit layer).
This makes it cumbersome to write X code in C. Much of the elegance of the
underlying X protocol has been lost among the deficiencies of a particular
language.
When using a more powerful language, like Scheme, it was interesting to try
to redo it all, with the X protocol as a starting point. The result is much
cleaner and much easier to understand as the SCIX environment is consistent
on all levels.
Yes, SCIX is definitely slower than an application written entirely in C, but
if speed is crucial then maybe the entire application should be written in C.
For applications that need to be written in Scheme, however, I think that the
power of the SCIX model of X can outweigh the speed gains that would come from
using the C bindings from within Scheme.
Yes, we do widgets in Scheme as well. They are typically quite easy to write.
A set of buttons (generic-, text- and pixmap-buttons) that we wrote currently
consists of 70, 35 and 20 lines of Scheme code each. The latter two inherit
the former...
--
Johan Ihren
Dept. of Computer Science,
Royal Institute of Technology, Stockholm, Sweden
Email: johani@nada.kth.se -or- <backbone>!sunic!nada!johani
------------------------------
End of Scheme Digest
********************
∂14-Feb-90 1445 @zurich.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu URGENT RESPONSE REQUESTED!!!!!
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 14 Feb 90 14:45:37 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA07595; Wed, 14 Feb 90 17:38:23 EST
Received: from skinner.cs.uoregon.edu (skinner.cs.uoregon.edu) by zurich.ai.mit.edu; Wed, 14 Feb 90 17:37:08 est
Received: from spencer.cs.uoregon.edu by skinner.cs.uoregon.edu with SMTP
(5.61.14/IDA-1.2.8) id AA05540; Wed, 14 Feb 90 14:36:48 -0800
Received: by spencer.cs.uoregon.edu; Wed, 14 Feb 90 14:38:51 PST
Date: Wed, 14 Feb 90 14:38:51 PST
From: will@cs.uoregon.edu
Message-Id: <9002142238.AA27288@spencer.cs.uoregon.edu>
To: rrrs-authors@zurich.ai.mit.edu
Subject: URGENT RESPONSE REQUESTED!!!!!
Cc: scheme-standard@zurich.ai.mit.edu
Several voices in the scheme-standard list have begun to urge that
the IEEE standard require #f and the empty list to be distinct.
It is becoming clear that we will never again have the opportunity
to make this change as painlessly as we can today.
I therefore request an extraordinary action: that the R*RS authors
agree, via electronic mail, to pass on the following message to
the IEEE working group on Scheme, P1178:
We, the R*RS authors, do not object to changing the IEEE draft
standard to require that #f be distinct from the empty list.
We are willing to change the R4RS to conform with the IEEE
standard if this change is made.
I would like to strengthen "do not object to" to "recommend", but
I think "do not object to" is enough for P1178 to consider the matter.
Let me remind you that the IEEE standard cannot become effective
much before the end of this year, and it is far easier to change
an implementation than a standard.
Please respond IMMEDIATELY. The IEEE draft is about to be submitted
for the balloting process.
Ken Dickey:
I understand that getting a consensus for disjointness of '() and #f is
probably not possible at this time and should properly be done in the RNRS
authors' group. Not having it done now will certainly come back to haunt
us.
Jon L White:
There must certainly be forces of conservatism in the Scheme community
too. But unless there is a widespread and nearly unmanageable application
-- a behemoth of the magnitude of MACSYMA -- or a bevy of commercial
implementations that will seriously be compromised by remaining firm
on this issue, then I would strongly encourage the radicals among you
to "do it right, this time".
Morry Katz:
....Since we are currently drafting the first Scheme
standard, we have the rare opportunity to rectify the traditional mistake of
allowing '() to act as a boolean. We should actually mandate the separation of
these types NOW. Once the first standard is produced, it will be too late to
rectify this problem. Forever after, people will strongly resist an
incompatible change to the standard.
Guy L Steele Jr:
This certainly seems to be yet another opportunity to correct
in Scheme a fundamental mistake in Common Lisp.
Peace, Will
∂14-Feb-90 1450 RPG@sail.stanford.edu re: URGENT RESPONSE REQUESTED!!!!!
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 14 Feb 90 14:50:47 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA07760; Wed, 14 Feb 90 17:46:19 EST
Received: from SAIL.Stanford.EDU (sail.stanford.edu) by zurich.ai.mit.edu; Wed, 14 Feb 90 17:45:08 est
Message-Id: <1Sjrm8@SAIL.Stanford.EDU>
Date: 14 Feb 90 1444 PST
From: Dick Gabriel <RPG@sail.stanford.edu>
Subject: re: URGENT RESPONSE REQUESTED!!!!!
To: will@cs.uoregon.edu, rrrs-authors@zurich.ai.mit.edu
Cc: scheme-standard@zurich.ai.mit.edu
[In reply to message from will@cs.uoregon.edu sent Wed, 14 Feb 90 14:38:51 PST.]
I agree with the change to make () and #f distinct, and I support Will's
proposed passage.
-rpg-
∂14-Feb-90 1500 jinx@zurich.ai.mit.edu disjointness of null? and boolean?
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 14 Feb 90 15:00:25 PST
Received: from zurich.ai.mit.edu ([18.43.0.171]) by life.ai.mit.edu (4.0/AI-4.10) id AA07895; Wed, 14 Feb 90 17:55:59 EST
Received: from localhost by zurich.ai.mit.edu; Wed, 14 Feb 90 17:54:54 est
Date: Wed, 14 Feb 90 17:54:54 est
From: jinx@zurich.ai.mit.edu (Guillermo J. Rozas)
Message-Id: <9002142254.AA26494@zurich.ai.mit.edu>
To: rrrs-authors@zurich.ai.mit.edu
Subject: disjointness of null? and boolean?
Reply-To: jinx@zurich.ai.mit.edu
This is a copy of the message I recently sent to scheme-standard.
Obviously the procedural objection does not hold.
From jinx Wed Feb 14 17:23:15 1990
To: mkatz@garlic.stanford.edu
CC: cph, scheme-standard
In-reply-to: Morris Katz's message of Wed, 14 Feb 90 13:21:30 PST <9002142121.AA09893@garlic.Stanford.EDU>
Subject: disjointness of types
Reply-to: jinx@zurich.ai.mit.edu
I wholeheartedly supported adding NULL? to IEEE scheme; however, I would
advocate going all the way. Since we are currently drafting the first Scheme
standard, we have the rare opportunity to rectify the traditional mistake of
allowing '() to act as a boolean. We should actually mandate the separation of
these types NOW. Once the first standard is produced, it will be too late to
rectify this problem. Forever after, people will strongly resist an
incompatible change to the standard.
LETS ACT NOW!
I object pretty strongly to requiring (eq? #f '()) -> #f. I have two
main objections:
1) (Purely procedural) The RNRS "committee" has not accepted this, and
the standard should not be incompatible with it. This is the wrong
forum to discuss this!
2) (Semantic) I think that the people who advocate for (eq? #f '()) ->
#f do so under a view of the world that is different from mine, but
neither better nor worse. I will present mine, since the other side
has presented its own many times:
Lists in Lisp are a convention, not a type. In particular, lists
always satisfy (at least) two predicates, either LIST? and PAIR?, or
LIST? and NULL?. The main type out of which they are built is the
pair, yet not all pairs are lists.
Lists are defined by the property that if they are not empty, their
CDRs are lists as well, and a finite number of nested applications of
CDR will yield the empty list.
I need some object to distinguish the empty list which, by definition,
will satisfy the predicate NULL?. This object has no other purpose in
life than to distinguish the empty list or end of a non-empty list,
and since it is the artifact of a convention, I should be able to
choose any object that I damn well please for this purpose, as long as
I use it consistently.
Thus I could choose the object 3, the object #t, the object 'NIL, the
object #f, or do the following:
(define empty-list
(let ((pair (cons 'unknown 'unknown)))
(set-car! pair pair)
(set-car! pair pair)
pair))
Although I don't mind other people creating a distinct object only for
this convention, please don't force me to do the same! I think it is
unnecessary and somewhat misguided.
Thus, I object strongly to requiring (eq? #f '()) -> #f
I object as well to describing NULL? as a type predicate, with
the restrictions that type predicates have.
∂14-Feb-90 1500 jinx@zurich.ai.mit.edu URGENT RESPONSE REQUESTED!!!!!
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 14 Feb 90 14:59:36 PST
Received: from zurich.ai.mit.edu ([18.43.0.171]) by life.ai.mit.edu (4.0/AI-4.10) id AA07874; Wed, 14 Feb 90 17:54:13 EST
Received: from localhost by zurich.ai.mit.edu; Wed, 14 Feb 90 17:52:36 est
Date: Wed, 14 Feb 90 17:52:36 est
From: jinx@zurich.ai.mit.edu (Guillermo J. Rozas)
Message-Id: <9002142252.AA26481@zurich.ai.mit.edu>
To: will@cs.uoregon.edu
Cc: rrrs-authors@zurich.ai.mit.edu, scheme-standard@zurich.ai.mit.edu
In-Reply-To: will@cs.uoregon.edu's message of Wed, 14 Feb 90 14:38:51 PST <9002142238.AA27288@spencer.cs.uoregon.edu>
Subject: URGENT RESPONSE REQUESTED!!!!!
Reply-To: jinx@zurich.ai.mit.edu
We, the R*RS authors, do not object to changing the IEEE draft
standard to require that #f be distinct from the empty list.
We are willing to change the R4RS to conform with the IEEE
standard if this change is made.
I object to this recommendation, and I will separately post to
rrrs-authors my rationale. I already posted my rationale to
scheme-standard.
∂14-Feb-90 1520 jinx@zurich.ai.mit.edu [jinx: disjointness of types]
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 14 Feb 90 15:20:21 PST
Received: from zurich.ai.mit.edu ([18.43.0.171]) by life.ai.mit.edu (4.0/AI-4.10) id AA08253; Wed, 14 Feb 90 18:16:55 EST
Received: from localhost by zurich.ai.mit.edu; Wed, 14 Feb 90 18:15:52 est
Date: Wed, 14 Feb 90 18:15:52 est
From: jinx@zurich.ai.mit.edu (Guillermo J. Rozas)
Message-Id: <9002142315.AA26712@zurich.ai.mit.edu>
To: rrrs-authors@zurich.ai.mit.edu
Subject: [jinx: disjointness of types]
Reply-To: jinx@zurich.ai.mit.edu
Sorry guys, I blew it. Here is the message
Date: Wed, 14 Feb 90 17:23:15 EST
From: jinx
To: mkatz@garlic.stanford.edu
CC: cph, scheme-standard
In-reply-to: Morris Katz's message of Wed, 14 Feb 90 13:21:30 PST <9002142121.AA09893@garlic.Stanford.EDU>
Subject: disjointness of types
Reply-to: jinx@zurich.ai.mit.edu
I wholeheartedly supported adding NULL? to IEEE scheme; however, I would
advocate going all the way. Since we are currently drafting the first Scheme
standard, we have the rare opportunity to rectify the traditional mistake of
allowing '() to act as a boolean. We should actually mandate the separation of
these types NOW. Once the first standard is produced, it will be too late to
rectify this problem. Forever after, people will strongly resist an
incompatible change to the standard.
LETS ACT NOW!
I object pretty strongly to requiring (eq? #f '()) -> #f. I have two
main objections:
1) (Purely procedural) The RNRS "committee" has not accepted this, and
the standard should not be incompatible with it. This is the wrong
forum to discuss this!
2) (Semantic) I think that the people who advocate for (eq? #f '()) ->
#f do so under a view of the world that is different from mine, but
neither better nor worse. I will present mine, since the other side
has presented its own many times:
Lists in Lisp are a convention, not a type. In particular, lists
always satisfy (at least) two predicates, either LIST? and PAIR?, or
LIST? and NULL?. The main type out of which they are built is the
pair, yet not all pairs are lists.
Lists are defined by the property that if they are not empty, their
CDRs are lists as well, and a finite number of nested applications of
CDR will yield the empty list.
I need some object to distinguish the empty list which, by definition,
will satisfy the predicate NULL?. This object has no other purpose in
life than to distinguish the empty list or end of a non-empty list,
and since it is the artifact of a convention, I should be able to
choose any object that I damn well please for this purpose, as long as
I use it consistently.
Thus I could choose the object 3, the object #t, the object 'NIL, the
object #f, or do the following:
(define empty-list
(let ((pair (cons 'unknown 'unknown)))
(set-car! pair pair)
(set-car! pair pair)
pair))
Although I don't mind other people creating a distinct object only for
this convention, please don't force me to do the same! I think it is
unnecessary and somewhat misguided.
Thus, I object strongly to requiring (eq? #f '()) -> #f
I object as well to describing NULL? as a type predicate, with
the restrictions that type predicates have.
∂14-Feb-90 1546 @zurich.ai.mit.edu,@RELAY.CS.NET,@tektronix.tek.com:kend@mrloog.wr.tek.com Re: disjointness of '() and #f
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 14 Feb 90 15:45:57 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA08541; Wed, 14 Feb 90 18:39:32 EST
Received: from RELAY.CS.NET (relay.cs.net) by zurich.ai.mit.edu; Wed, 14 Feb 90 18:38:31 est
Received: from tektronix.tek.com by RELAY.CS.NET id aa21398; 14 Feb 90 17:38 EST
Received: by tektronix.TEK.COM (5.51/7.1)
id AA23246; Wed, 14 Feb 90 15:41:55 PST
Received: by wrgate.wr.tek.com (5.51/7.1)
id AA06387; Wed, 14 Feb 90 15:38:15 PST
Received: by mrloog.WR.TEK.COM (1.2/7.1)
id AA11397; Wed, 14 Feb 90 15:38:18 pst
Message-Id: <9002142338.AA11397@mrloog.WR.TEK.COM>
To: will%cs.uoregon.edu@relay.cs.net
Cc: rrrs-authors@zurich.ai.mit.edu, scheme-standard@zurich.ai.mit.edu,
kend@mrloog.wr
Subject: Re: disjointness of '() and #f
In-Reply-To: Your message of Wed, 14 Feb 90 14:38:51 PST.
<9002142238.AA27288@spencer.cs.uoregon.edu>
Date: 14 Feb 90 15:38:08 PST (Wed)
From: kend%mrloog.wr.tek.com@relay.cs.net
Another factor arguing for disjointness has been raised but unstated for
some time. Disjointness [(eq? '() #f) -> #f] is much easier to explain
to students as it accords with their intuitive notions. There are areas
where Scheme differs from naive intuition for deep reasons (e.g.
exactness). It would be nice to be able to concentrate on areas where
there really are deep issues rather than areas of happenstance.
I see no problem with making disjointness of predicates BOOLEAN? and
NULL? in the IEEE Scheme Standard and allowing (e.g. Jinx) to redefine
BOOLEAN?, NULL?, LIST?, PAIR?, CONS, et cetera for idiosyncratic
purposes. As long as such *conventions* can be implemented in a standard
Scheme, there is no creative restriction and many people are saved from
needless confusion.
I would be very interested in deep reasons why such confusion should be
mandated.
Jinx, if you can explain to my simple self why you cannot redefine a
scheme implementation which follows the standard to do what you want in
this case, please do so. If not, I request that you remove your
objections.
-Ken Dickey
∂14-Feb-90 1612 jinx@zurich.ai.mit.edu disjointness of '() and #f
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 14 Feb 90 16:12:07 PST
Received: from zurich.ai.mit.edu ([18.43.0.171]) by life.ai.mit.edu (4.0/AI-4.10) id AA08910; Wed, 14 Feb 90 19:07:39 EST
Received: from localhost by zurich.ai.mit.edu; Wed, 14 Feb 90 19:05:47 est
Date: Wed, 14 Feb 90 19:05:47 est
From: jinx@zurich.ai.mit.edu (Guillermo J. Rozas)
Message-Id: <9002150005.AA27203@zurich.ai.mit.edu>
To: kend%mrloog.wr.tek.com@relay.cs.net
Cc: will%cs.uoregon.edu@relay.cs.net, rrrs-authors@zurich.ai.mit.edu,
scheme-standard@zurich.ai.mit.edu, kend@mrloog.wr
In-Reply-To: kend%mrloog.wr.tek.com@RELAY.CS.NET's message of 14 Feb 90 15:38:08 PST (Wed) <9002142338.AA11397@mrloog.WR.TEK.COM>
Subject: disjointness of '() and #f
Reply-To: jinx@zurich.ai.mit.edu
Another factor arguing for disjointness has been raised but unstated for
some time. Disjointness [(eq? '() #f) -> #f] is much easier to explain
to students as it accords with their intuitive notions. There are areas
where Scheme differs from naive intuition for deep reasons (e.g.
exactness). It would be nice to be able to concentrate on areas where
there really are deep issues rather than areas of happenstance.
This comes from a very widespread way of teaching things that will
ultimately lead to confusion about lists and pairs. The problem is
that typically lists are introduced as primitive or quasi-primitive
types and then students get confused when they start playing with both
lists and pairs.
The most consistent way that I've seen to avoid the whole problem
altogether is to do the following (which is the approach mainly
followed in SICP):
Pairs are primitive, lists are not.
cons, car, and cdr operate exclusively on pairs.
As a convention, we build lists on top of them by distinguishing some
arbitrary object as the end of all lists and the empty list. I don't
advocate for this distinguished object to be #f, I just don't want you
to force me to have a magic object just for this purpose. #f happens
to be a convenient such object to choose. It is only a convention
that can be violated at any time.
The confusion comes because the WRITE procedure is byassed towards
lists, and furthermore in some implementations where (eq? '() #f) is
true, #f prints as "()". I think the printer is at fault, since the
essential (not conventional) meaning of this object is as #f, not as
'().
Jinx, if you can explain to my simple self why you cannot redefine a
scheme implementation which follows the standard to do what you want in
this case, please do so. If not, I request that you remove your
objections.
You can obviously do the same yourself by redefining all list
operations. The situation is symmetric.
I don't want to force you to make them eq? I just don't want you to
force me to make them distinct.
I thought we had stopped arguing about this one a while ago. Please
let things be.
∂14-Feb-90 1734 eb@lucid.com disjointness of '() and #f
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 14 Feb 90 17:34:17 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA10147; Wed, 14 Feb 90 20:30:55 EST
Received: from lucid.com (lucid.com) by zurich.ai.mit.edu; Wed, 14 Feb 90 20:28:58 est
Received: from sunvalleymall ([192.31.212.14]) by heavens-gate.lucid.com id AA09439g; Wed, 14 Feb 90 17:28:39 PST
Received: by sunvalleymall id AA12333g; Wed, 14 Feb 90 17:29:00 PST
Date: Wed, 14 Feb 90 17:29:00 PST
From: Eric Benson <eb@lucid.com>
Message-Id: <9002150129.AA12333@sunvalleymall>
To: jinx@zurich.ai.mit.edu
Cc: kend%mrloog.wr.tek.com@relay.cs.net, will%cs.uoregon.edu@relay.cs.net,
rrrs-authors@zurich.ai.mit.edu, scheme-standard@zurich.ai.mit.edu,
kend@mrloog.wr
In-Reply-To: Guillermo J. Rozas's message of Wed, 14 Feb 90 19:05:47 est <9002150005.AA27203@zurich.ai.mit.edu>
Subject: disjointness of '() and #f
Date: Wed, 14 Feb 90 19:05:47 est
From: jinx@zurich.ai.mit.edu (Guillermo J. Rozas)
Reply-To: jinx@zurich.ai.mit.edu
As a convention, we build lists on top of them by distinguishing some
arbitrary object as the end of all lists and the empty list. I don't
advocate for this distinguished object to be #f, I just don't want you
to force me to have a magic object just for this purpose. #f happens
to be a convenient such object to choose. It is only a convention
that can be violated at any time.
#F happens to be a very INconvenient such object to choose, because
historically it has been identified as the one and only object that is
the empty list. This leads to the punning we are all familiar with,
and which disjointness is designed to eliminate.
Suppose your Lisp system selected an object "at random" to be the
empty list each time it was started. Sometimes it would be the number
239, sometimes it would be a procedure (lambda () #t), sometimes it
would be the symbol NIL, sometimes it would be #F. Once selected at
startup it would never change, but you would have no way of predicting
what value it would take. There is no magic object that is the empty
list. Would this arrangement be satisfactory to you? (Let's ignore
the cost of implementing it.) What is the interesting difference
between this world, and the "unique empty list" world? In fact, the
unique empty list world looks like the asymptotic limit of the "Queen
for a Day" world, and much easier to implement!
One of the functions of Scheme in the world of Lisp (not to mention of
standardization in general) is to codify and rationalize conventions.
As a convention, we represent boolean values by distinguishing some
arbitrary object as falsehood. NIL happens to be a convenient object
to choose. On further reflection, we choose two objects distinct from
all others, #T and #F, to represent truth and falsehood. As a
convention, we represent functions as lists whose CAR is the symbol
LAMBDA. On further reflection, we create a new data type distinct
from all others to represent functions.
∂14-Feb-90 1743 @zurich.ai.mit.edu,@RELAY.CS.NET,@tektronix.tek.com:kend@mrloog.wr.tek.com Re: disjointness of '() and #f
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 14 Feb 90 17:43:19 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA10289; Wed, 14 Feb 90 20:38:46 EST
Received: from RELAY.CS.NET (relay.cs.net) by zurich.ai.mit.edu; Wed, 14 Feb 90 20:37:30 est
Received: from tektronix.tek.com by RELAY.CS.NET id aa24002; 14 Feb 90 19:37 EST
Received: by tektronix.TEK.COM (5.51/7.1)
id AA27414; Wed, 14 Feb 90 17:41:01 PST
Received: by wrgate.wr.tek.com (5.51/7.1)
id AA08025; Wed, 14 Feb 90 17:37:16 PST
Received: by mrloog.WR.TEK.COM (1.2/7.1)
id AA16331; Wed, 14 Feb 90 17:38:35 pst
Message-Id: <9002150138.AA16331@mrloog.WR.TEK.COM>
To: jinx@zurich.ai.mit.edu
Cc: rrrs-authors@zurich.ai.mit.edu, scheme-standard@zurich.ai.mit.edu
Subject: Re: disjointness of '() and #f
In-Reply-To: Your message of Wed, 14 Feb 90 19:05:47 est.
<9002150005.AA27203@zurich.ai.mit.edu>
Date: 14 Feb 90 17:38:25 PST (Wed)
From: kend%mrloog.wr.tek.com@relay.cs.net
>>
>> Jinx, if you can explain to my simple self why you cannot redefine a
>> scheme implementation which follows the standard to do what you want in
>> this case, please do so. If not, I request that you remove your
>> objections.
>>
>> You can obviously do the same yourself by redefining all list
>> operations. The situation is symmetric.
>>
>> I don't want to force you to make them eq? I just don't want you to
>> force me to make them distinct.
I would rather have them distinct by default and force you (personally)
to make them otherwise than force a large number of explanations on a
large number of people. Forcing portable code which wants distinctness
to redefine all list operations is not reasonable in this context.
>> I thought we had stopped arguing about this one a while ago. Please
>> let things be.
>>
If I were arguing for myself, this would be one thing. I am trying to
presuade you to remove your objection because of the large number of
people who are going to be bitten by this and the (I suspect hundreds of)
wasted man-hours this lack of distinction is going to cause. Proper
educational presentation can help, but the history is that (eq? #f '())
--> #t creates a real (objective) problem.
The simple solution is to avoid the problem. I have not yet heard other
than personal preference. [Perhaps I need to listen harder; perhaps you
need to talk louder].
-Ken
∂14-Feb-90 1828 Pavel_Curtis.PARC@xerox.com Re: URGENT RESPONSE REQUESTED!!!!!
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 14 Feb 90 18:27:54 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA10763; Wed, 14 Feb 90 21:22:48 EST
Received: from Xerox.COM (xerox.com) by zurich.ai.mit.edu; Wed, 14 Feb 90 21:21:43 est
Received: from Concord.ms by ArpaGateway.ms ; 14 FEB 90 17:32:33 PST
Sender: "Pavel_Curtis.PARC"@xerox.com
Date: 14 Feb 90 17:31:42 PST (Wednesday)
Subject: Re: URGENT RESPONSE REQUESTED!!!!!
From: "Pavel_Curtis.PARC"@xerox.com
To: will@cs.uoregon.edu
Cc: rrrs-authors@zurich.ai.mit.edu, scheme-standard@zurich.ai.mit.edu
Message-Id: <900214-173233-10479@Xerox>
I also support Will's proposal. I do not agree with Jinx's arguments
that lists are "just" a convention. They are too important to be tossed
off so informally. If such a convention is so central to the language,
then it should be done right. And the right thing is to avoid using one
value for two semantically unrelated purposes.
Pavel
∂14-Feb-90 1850 jmiller@macadamia.ai.mit.edu '() vs #F AND assignment to t-l vars.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 14 Feb 90 18:50:06 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA11000; Wed, 14 Feb 90 21:45:13 EST
Received: from chaos.cs.brandeis.edu (chaos.cs.brandeis.edu) by zurich.ai.mit.edu; Wed, 14 Feb 90 21:42:00 est
Received: from macadamia.cs.brandeis.edu by chaos.cs.brandeis.edu Wed, 14 Feb 90 21:42:18 -0500
Received: by macadamia (5.57/UofC3.0)
id AA00716; Wed, 14 Feb 90 21:39:47 EST
Date: Wed, 14 Feb 90 21:39:47 EST
From: Jim Miller <jmiller@macadamia.ai.mit.edu>
Message-Id: <9002150239.AA00716@macadamia>
To: scheme-standard@zurich.ai.mit.edu, rrrs-authors@zurich.ai.mit.edu
Subject: '() vs #F AND assignment to t-l vars.
Reply-To: JMiller@chaos.cs.brandeis.edu.cs.brandeis.edu
I find it hard to distinguish these two forums at this point. My
apologies if I offend anyone by double receipt or a feeling that the
addressing is inappropriate.
(a) Is '() EQ? to #F
It is my understanding that in both R(4-epsilon)RS and IEEE, any
conforming -program- must consider them to be distinct because there
exist conforming implementations that distintinguish them. As far as
I am concerned this is sufficient; I prefer not to coerce implementors
where it can be avoided. On the other hand, it can't be denied that
both the IEEE and R4RS will be simpler to read if we require
implementations (not just programs) to distinguish #F from '(). For
this reason I disagree with Jinx and feel that we should break
historical precedent and require the distinction.
On a procedural note: it has been the uniform policy of "the authors"
to allow any single individual to veto a motion (that is the meaning
of consensus). The IEEE WG does not operate on consensus, but has a
strong precedent of making no binding technical decisions without a
formal meeting (i.e. not via the net) and has a standing policy that
no change incompatible with R4RS be made without such a meeting.
Under the circumstances, then, it seems to me that this matter is
closed. There is a strong objection to the request that the authors
suggest a change, and the working group has no planned meeting.
I see only three options: Jinx withdraws his objection; the IEEE WG
votes by e-mail to reconvene and delay the standard by four months; or
the standard does not coerce implementations to distinguish #F from
'().
(b) Assignments to top-level bindings of names specified in the Draft
Standard. I will not complicate the discussion much further. There
is one point that must be clarified, however. Will and others
incorrectly state that the proposed wording makes it an error to
assign to a top level binding of a variable specified in the Standard
without first defining it. It is not an error -- that would suggest
that implementations are encouraged to detect the occurrence and
report it to the user -- instead we deliberately phrased it as "a
conforming program may not contain an assignment..." This wording
follows from my general "non coercion rule" above: implementations may
do as they choose, but portable programs can't depend on the results.
For your convenience, I repeat the proposed paragraph below. I urge
you to read it as carefully as we wrote it (it took us over two hours
to understand the issues and write these three sentences). Please
consider the following facts:
(a) There exist two kinds of implementations: those that distinguish
DEFINITION from ASSIGNMENT at the top level (perhaps they have
multiple top level environments or they choose to separate the user's
top level environment from a system level environment) and those that
identify these two operations.
(b) There are, in essence, four categories of variables at the top
level: (1) those specified in the standard (and hence visible there),
(2) those defined by the program (some of which may have the same
names as the predefined ones and therefore shadowing them as far as
the program is concerned), (3) those defined by the implementation but
not the standard, and (4) those that have no visible binding. For
each of these four categories and two kinds of implementations, you
must understand what it means to DEFINE and ASSIGN the variable in
question.
Conforming programs may contain top level definitions of -any-
variable. In a conforming implementation, no definition shall
modify the behavior of any procedure specified in this Standard.
A conforming program may not contain an assignment to a variable
in the top level environment unless it has previously bound that
variable with a top level definition; the effect of such
assignments is unspecified.
For the record: I'm happy to reword this (I admit it is unclear as
stated) once I understand the general sentiment, and I have no truly
strong feelings about how it should go. On the other hand, I will be
in the position of having to explain this to outsiders during the
balloting period and I will need a good understanding of the rationale
at that time. It is important, therefore, that this community
seriously consider the issue from all angles. That means thinking
about all 16 possible top-level operations alluded to above!
Sorry this is so long.
--Jim
∂14-Feb-90 2013 arthur@zurich.ai.mit.edu disjointness of '() and #f
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 14 Feb 90 20:13:32 PST
Received: from zurich.ai.mit.edu ([18.43.0.169]) by life.ai.mit.edu (4.0/AI-4.10) id AA12035; Wed, 14 Feb 90 23:10:44 EST
Received: from localhost by zurich.ai.mit.edu; Wed, 14 Feb 90 23:09:58 est
Date: Wed, 14 Feb 90 23:09:58 est
From: arthur@zurich.ai.mit.edu (Arthur Gleckler)
Message-Id: <9002150409.AA27976@zurich.ai.mit.edu>
To: kend%mrloog.wr.tek.com@relay.cs.net
Cc: scheme-standard@zurich.ai.mit.edu, rrrs-authors@zurich.ai.mit.edu
In-Reply-To: kend%mrloog.wr.tek.com@RELAY.CS.NET's message of 14 Feb 90 15:38:08 PST (Wed) <9002142338.AA11397@mrloog.WR.TEK.COM>
Subject: disjointness of '() and #f
Reply-To: arthur@zurich.ai.mit.edu
Date: 14 Feb 90 15:38:08 PST (Wed)
From: kend%mrloog.wr.tek.com@RELAY.CS.NET
Another factor arguing for disjointness has been raised but unstated for
some time. Disjointness [(eq? '() #f) -> #f] is much easier to explain
to students as it accords with their intuitive notions. There are areas
where Scheme differs from naive intuition for deep reasons (e.g.
exactness). It would be nice to be able to concentrate on areas where
there really are deep issues rather than areas of happenstance.
I don't understand arguments from student intuition, particularly this one.
Saying that #f marks ends of lists is just as clear as saying that
X | (null? X)
marks ends of lists. Notions like disjointness of types are less intuitive
than simple conventions like "#f marks ends of lists."
I see no problem with making disjointness of predicates BOOLEAN? and
NULL? in the IEEE Scheme Standard and allowing (e.g. Jinx) to redefine
BOOLEAN?, NULL?, LIST?, PAIR?, CONS, et cetera for idiosyncratic
purposes. As long as such *conventions* can be implemented in a standard
Scheme, there is no creative restriction and many people are saved from
needless confusion.
I would be very interested in deep reasons why such confusion should be
mandated.
Jinx, if you can explain to my simple self why you cannot redefine a
scheme implementation which follows the standard to do what you want in
this case, please do so. If not, I request that you remove your
objections.
If I assume that () and #f will be eq? in all implementations and write my code
accordingly, I'm making a mistake. I should clearly use null? to detect ends
of lists EVEN THOUGH I KNOW THAT MY IMPLEMENTATION MAKES () AND #F EQUIVALENT,
but that's no reason that () and #F shouldn't be equivalent in some
implementations (for whatever reasons). After all, if I write
(+ '(a b c) '(d e))
to append two lists knowing that my implementation of Scheme defines + on both
numbers and lists, I shouldn't expect to get the right answer on other
implementations. The language should not have to clean up after careless
programmers, after all. To say that Jinx is doing this for "idiosyncratic
purposes" is just unfriendly.
∂15-Feb-90 0043 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #301
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 15 Feb 90 00:43:06 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA15700; Thu, 15 Feb 90 03:40:52 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Thu, 15 Feb 90 03:39:43 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa18013;
15 Feb 90 3:10 EST
Message-Id: <DIGEST.184.900215.023328.5@MC.LCS.MIT.EDU>
Date: 15 Feb 90 02:33:28 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #301
Scheme Digest #301 15 Feb 90 02:33:28 EST
Today's Topics:
Scheme macros for TeX
CSCHEME under VMS
Fast Scheme for Suns? (2 messages)
Functional / algebraic languages for DS3100
David Betz's email address ?
----------------------------------------------------------------------
Message-ID: <11278@thor.acc.stolaf.edu>
Date: 14 Feb 90 05:16:53 GMT
From: Scott Fritchie <snorkelwacker!usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!nic.MR.NET!thor.acc.stolaf.edu!fritchie@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Scheme macros for TeX
I've been typesetting Scheme for Computer Science course examinations
and handouts using TeX, but I don't have any nice macros packages to deal
with the dirty-work of aligning parentheses, etc. and would be interested
in a macro package to get rid of kludgy \kern's :-(
I heard a rumor that such a package was available via anon. FTP from
linus.mitre.org, but it has been unreachable for the past week. Are there
any other FTP sites/places/people I might find such a beast?
-Scott
---
Scott Fritchie, Systems Programmer and Postmaster
St. Olaf College, Northfield, MN 55057 USA
Domain: fritchie@acc.stolaf.edu UUCP: ..!umn-cs!stolaf!fritchie
"Yeah, boss, I'll be in late today. UNIX refuses to boot on my Ford."
------------------------------
Message-ID: <9002141532.AA28905@schizo.samsung.com>
Date: Wed, 14 Feb 90 09:35:36 EDT
From: gjc@mitech.com
Reply-To: gjc@mitech.com
To: scheme@mc.lcs.mit.edu
Subject: CSCHEME under VMS
For CSCHEME under VMS one might want to look at the code distributed
by DECUS. In particular CD-ROM collection 4 or 5 has a languages-and-tools
collection which includes CSCHEME, GNU CC, TEX, and megabytes of other code.
------------------------------
Message-ID: <2399@randvax.UUCP>
Date: 13 Feb 90 23:44:03 GMT
From: Brian Leverich <leverich@RAND.ORG>
To: scheme@mc.lcs.mit.edu
Subject: Fast Scheme for Suns?
I've been doing knowledge-based simulation modeling of the Army's wartime
theater ammunition distribution system using ROSS built on top of Texas
Instruments' PC-Scheme, but things have grown to the point (as they usually
do in simulation modeling...) where I need more processing horsepower.
Anybody have any experience with a Scheme that will run on Sun UNIX
boxes? Ideally I'd like a Scheme that is public domain, high optimized,
and compatible with PC-Scheme, but I'll take whatever is available.
Thanks for suggestions! -B
--
"Simulate it in ROSS"
Brian Leverich | U.S. Snail: 1700 Main St.
ARPAnet: leverich@rand.org | Santa Monica, CA 90406
UUCP: decvax!randvax!leverich | Ma Bell: (213) 393-0411 X7769
------------------------------
Message-ID: <1990Feb14.190515.4402@ncsuvx.ncsu.edu>
Date: 14 Feb 90 19:05:15 GMT
From: "John W. Baugh Jr." <news@ncsuvx.ncsu.edu>
To: scheme@mc.lcs.mit.edu
Subject: Functional / algebraic languages for DS3100
Apparently NJML is soon to be released for the pmax. My
question is `Are there any (currently available) alternatives?'
By alternatives I mean a `modern' functional language with
disjoint union data constructors, pattern matching, etc.
I heard that a scheme-based interpreter exists for Haskell--is
that true? If so, would it run on T (using the scheme mode)?
Finally, are interpreters for algebraic languages like obj3
readily available?
John Baugh
------------------------------
Message-ID: <EHO.90Feb14042113@word.Princeton.EDU>
Date: 14 Feb 90 09:21:13 GMT
From: Eric Ho <phoenix!phoenix.princeton.edu!eho@princeton.edu>
To: scheme@mc.lcs.mit.edu
Subject: David Betz's email address ?
Has anyone got David Betz's email address handy ?
Any pointers appreciated.
--
Eric Ho
Princeton University
eho@clarity.princeton.edu
------------------------------
Message-ID: <6784@ubc-cs.UUCP>
Date: 15 Feb 90 02:49:13 GMT
From: Vincent Manis <ubc-cs!manis@beaver.cs.washington.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: Fast Scheme for Suns?
In article <2399@randvax.UUCP> leverich@rand.org (Brian Leverich) writes:
>Anybody have any experience with a Scheme that will run on Sun UNIX
>boxes? Ideally I'd like a Scheme that is public domain, high optimized,
>and compatible with PC-Scheme, but I'll take whatever is available.
We have been using Chez Scheme, a commercial product which runs on
Apollo DN3000/3500's, Sun-3's (I don't remember if it runs on Sun-4's),
and VAXen. It is an outstanding system, comprising a very
high-performance compiler and a complete language implementation.
It isn't very expensive (I don't have the price list at hand, but it
runs about US$1K per copy, with site licencing at about $10K, and
educational discounts of 50%), but it's an excellent value.
The publisher is Cadence Research, in Bloomington, Indiana. Sorry, but I
also don't have Cadence's address at hand, but you can email to Kent
Dybvig <cadence!dyb@iuvax.cs.indiana.edu> for more information.
--
\ Vincent Manis <manis@cs.ubc.ca> "There is no law that vulgarity and
\ Department of Computer Science literary excellence cannot coexist."
/\ University of British Columbia -- A. Trevor Hodge
/ \ Vancouver, BC, Canada V6T 1W5 (604) 228-2394
------------------------------
End of Scheme Digest
********************
∂15-Feb-90 0307 ramsdell@linus.mitre.org Re: URGENT RESPONSE REQUESTED!!!!!
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 15 Feb 90 03:07:49 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA17014; Thu, 15 Feb 90 06:03:50 EST
Received: from linus.mitre.org ([129.83.100.103]) by zurich.ai.mit.edu; Thu, 15 Feb 90 06:02:57 est
Received: from huxley.mitre.org by linus.mitre.org (5.61/RCF-4S)
id AA01442; Thu, 15 Feb 90 06:00:37 -0500
Posted-Date: Thu, 15 Feb 90 06:00:26 EST
Received: by huxley.mitre.org (5.61/RCF-4C)
id AA03477; Thu, 15 Feb 90 06:00:28 -0500
From: ramsdell@linus.mitre.org
Message-Id: <9002151100.AA03477@huxley.mitre.org>
To: rrrs-authors@zurich.ai.mit.edu, scheme-standard@wheaties.ai.mit.edu
Subject: Re: URGENT RESPONSE REQUESTED!!!!!
In-Reply-To: Your message of Wed, 14 Feb 90 14:38:51 -0800.
<9002142238.AA27288@spencer.cs.uoregon.edu>
Date: Thu, 15 Feb 90 06:00:26 EST
I strongly support any move to make '() and #f distinct.
∂15-Feb-90 0456 xerox@cs.vu.nl Re: URGENT RESPONSE REQUESTED!!!!!
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 15 Feb 90 04:56:31 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA17772; Thu, 15 Feb 90 07:48:24 EST
Received: from mcsun.EU.net (mcsun.eu.net) by zurich.ai.mit.edu; Thu, 15 Feb 90 07:47:32 est
Received: by mcsun.EU.net with SMTP; Thu, 15 Feb 90 13:47:41 +0100 (MET)
Received: from [192.31.231.43] by hp4nl.nluug.nl with SMTP
id AA05762 (5.58.1.14/2.14); Thu, 15 Feb 90 13:48:54 +0100
Received: from ski.cs.vu.nl by top.cs.vu.nl id aa22382; 15 Feb 90 13:44 MET
Date: Thu, 15 Feb 90 13:43:41 MET
From: "J. A. Durieux" <xerox@cs.vu.nl>
To: xerox@cs.vu.nl
Cc: rrrs-authors@zurich.ai.mit.edu, scheme-standard@wheaties.ai.mit.edu
Subject: Re: URGENT RESPONSE REQUESTED!!!!!
Message-Id: <9002151343.aa09683@ski.cs.vu.nl>
One common problem I run into when #F == () is to distinguish
between failure and an empty successful response,
e.g. of a matcher or unifyer. [Plug for failure semantics ... :-)]
My common way around has been to build the response list on e.g. #T
instead of #F. (Other solutions, like an extra cons around the
answer, are much uglier.)
But alas, in Scheme all standard functions (like assoc, member, etc.)
refuse to deal with such a "non-proper" (sic!) list.
So, *if* it has to remain acceptable that lists may end in #F,
one should allow them to end in other values as well (just #T
would do). Of course, that is no acceptable solution,
given the state of affairs, so:
I am strongly in favour of distinguishing #F and ().
Sorry for my clumsy English,
J. A. "Biep" Durieux
∂15-Feb-90 0724 jinx@zurich.ai.mit.edu URGENT RESPONSE REQUESTED!!!!!
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 15 Feb 90 07:24:25 PST
Received: from zurich.ai.mit.edu ([18.43.0.171]) by life.ai.mit.edu (4.0/AI-4.10) id AA19354; Thu, 15 Feb 90 10:20:57 EST
Received: from localhost by zurich.ai.mit.edu; Thu, 15 Feb 90 10:20:16 est
Date: Thu, 15 Feb 90 10:20:16 est
From: jinx@zurich.ai.mit.edu (Guillermo J. Rozas)
Message-Id: <9002151520.AA01391@zurich.ai.mit.edu>
To: xerox@cs.vu.nl
Cc: xerox@cs.vu.nl, rrrs-authors@zurich.ai.mit.edu,
scheme-standard@wheaties.ai.mit.edu
In-Reply-To: "J. A. Durieux"'s message of Thu, 15 Feb 90 13:43:41 MET <9002151343.aa09683@ski.cs.vu.nl>
Subject: URGENT RESPONSE REQUESTED!!!!!
Reply-To: jinx@zurich.ai.mit.edu
One common problem I run into when #F == () is to distinguish
between failure and an empty successful response,
e.g. of a matcher or unifyer. [Plug for failure semantics ... :-)]
This is a problem inherent in #f, not having much to do with whether
it is the empty list as well or not. Say that you have a program that
will return a particular piece of a structure if it exists or #f if it
does not. Perhaps the piece of structure is #f itself. You would
find yourself in the same bind, and we haven't even mentioned lists,
whether empty or not.
The correct (as far as I'm concerned) way to write such programs is to
return (by means of cps, or whatever) two values to the caller. One
is a success value, the other is the actual value found if the program
succeeded. There is no ambiguity then, or strange values being passed
around.
So, *if* it has to remain acceptable that lists may end in #F,
one should allow them to end in other values as well (just #T
would do). Of course, that is no acceptable solution,
given the state of affairs, so:
The question then would be how to recognize the end of a list?
In other words, what would NULL? do.
Traditionally (null? x) = (eq? x '())
which would be harder to accomodate if many objects terminated lists.
∂15-Feb-90 0725 jh@funet.fi URGENT RESPONSE REQUESTED!!!!!
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 15 Feb 90 07:25:11 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA19340; Thu, 15 Feb 90 10:19:18 EST
Received: from funet.fi (funet.fi) by zurich.ai.mit.edu; Thu, 15 Feb 90 10:18:20 est
Received: by funet.fi; id AA24052; Thu, 15 Feb 90 16:56:46 +0200
Message-Id: <9002151456.AA24052@funet.fi>
Date: Thu, 15 Feb 90 16:56:46 +0200
From: jh@funet.fi (Juha Hein{nen)
To: ramsdell@linus.mitre.org
Cc: rrrs-authors@zurich.ai.mit.edu, scheme-standard@wheaties.ai.mit.edu
In-Reply-To: ramsdell@linus.mitre.org's message of Thu, 15 Feb 90 06:00:26 EST <9002151100.AA03477@huxley.mitre.org>
Subject: URGENT RESPONSE REQUESTED!!!!!
I strongly support any move to make '() and #f distinct.
Me too. The history should not repeat itself in this case and we
should use the opportunity to make it right.
-- Juha Heinanen
∂15-Feb-90 0806 daniel@mojave.stanford.edu #f, '(), and true radicalism.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 15 Feb 90 08:03:17 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA19896; Thu, 15 Feb 90 10:59:04 EST
Received: from mojave.Stanford.EDU (mojave.stanford.edu) by zurich.ai.mit.edu; Thu, 15 Feb 90 10:58:03 est
Received: by mojave.Stanford.EDU (5.57/Ultrix2.4-C)
id AA27317; Thu, 15 Feb 90 07:55:05 PST
Date: Thu, 15 Feb 90 07:55:05 PST
From: daniel@mojave.stanford.edu (Daniel Weise)
Message-Id: <9002151555.AA27317@mojave.Stanford.EDU>
To: will@cs.uoregon.edu
Cc: rrrs-authors@zurich.ai.mit.edu, scheme-standard@zurich.ai.mit.edu
In-Reply-To: will@cs.uoregon.edu's message of Wed, 14 Feb 90 14:38:51 PST <9002142238.AA27288@spencer.cs.uoregon.edu>
Subject: #f, '(), and true radicalism.
We, the R*RS authors, do not object to changing the IEEE draft
standard to require that #f be distinct from the empty list.
We are willing to change the R4RS to conform with the IEEE
standard if this change is made.
This is such a small issue. To me the question is not which token is
used to denote the empty list. (Unless lists become primitive types,
with their own operations separate from those on pairs, I sort of
agree with Jinx. Though if it came to a vote I would support the
proposal.)
I care more about truth and falsity than about the list termination
conventions. To me the question is how IF treats its predicate value.
As long as a predicate of '() and #f mean take the false branch, and
all other values mean take the true branch, there will be horrible
punning and accidentally unportable code. To me, the best of all
possible worlds is making boolean values be distinct types, and only
allow IF to accept booleans as predicates. Second best would be to
have a distinct #f for false, and let '() as a predicate mean either
true or signal an error.
So, if the proposal is a way of later tightening the meaning of booleans
and IF, then it makes sense to me. Otherwise we are just arguing over
a simple convention that should be hidden by the two abstractions
*NIL* and NULL?. If we agreed on the abstractions we wouldn't have
worry about the implementation.
Daniel
∂15-Feb-90 0949 @zurich.ai.mit.edu,@RELAY.CS.NET,@tektronix.tek.com:kend@mrloog.wr.tek.com Re: disjointness of '() and #f
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 15 Feb 90 09:48:41 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA21533; Thu, 15 Feb 90 12:42:58 EST
Received: from RELAY.CS.NET (relay.cs.net) by zurich.ai.mit.edu; Thu, 15 Feb 90 12:41:56 est
Received: from tektronix.tek.com by RELAY.CS.NET id aa14500; 15 Feb 90 11:42 EST
Received: by tektronix.TEK.COM (5.51/7.1)
id AA17674; Thu, 15 Feb 90 09:45:10 PST
Received: by wrgate.wr.tek.com (5.51/7.1)
id AA18791; Thu, 15 Feb 90 09:41:28 PST
Received: by mrloog.WR.TEK.COM (1.2/7.1)
id AA20666; Thu, 15 Feb 90 09:41:18 pst
Message-Id: <9002151741.AA20666@mrloog.WR.TEK.COM>
To: arthur@zurich.ai.mit.edu
Cc: scheme-standard@zurich.ai.mit.edu, rrrs-authors@zurich.ai.mit.edu,
kend@mrloog.wr
Subject: Re: disjointness of '() and #f
In-Reply-To: Your message of Wed, 14 Feb 90 23:09:58 est.
<9002150409.AA27976@zurich.ai.mit.edu>
Date: 15 Feb 90 09:41:07 PST (Thu)
From: kend%mrloog.wr.tek.com@relay.cs.net
Arthur Gleckler writes:
>>
>> Another factor arguing for disjointness has been raised but unstated for
>> some time. Disjointness [(eq? '() #f) -> #f] is much easier to explain
>> to students as it accords with their intuitive notions. There are areas
>> where Scheme differs from naive intuition for deep reasons (e.g.
>> exactness). It would be nice to be able to concentrate on areas where
>> there really are deep issues rather than areas of happenstance.
>>
>> I don't understand arguments from student intuition, particularly this one.
>> Saying that #f marks ends of lists is just as clear as saying that
>>
>> X | (null? X)
>>
>> marks ends of lists. Notions like disjointness of types are less intuitive
>> than simple conventions like "#f marks ends of lists."
>>
Let me take a stab at presenting the problem. It is very convenient to
have a language-defined object which has a unique type. The rubric I see
many people (including myself) try to use is:
"never use #f in a data context, only in a control context".
This is a frequent source of confusion in data structures where 2 pieces
of information is desired: (1) was an action successful? (2) if
successful, what was the value of the result? [multiple value returns is
another discussion]. As (2) is only interesting in the success case, the
attempt is made to overload the returned value for two uses. E.g.
(let ( (probe (table-lookup table key)) )
(if probe
(success-action probe)
(failure-action)
) )
This works as long as the value of PROBE is #f XOR a valid data value.
There are a couple of ways that people try to `patch' this behavior. One
way is by packaging the result in a data structure [it then has to be
`unwrapped']. The other way is to pass success and failure continuations
into the lookup routine [this makes interesting and confusing reading to
novice Scheme programmers as they puzzle out the control flow]. Using a
user-defined unique value [e.g. (define moby-foo (lambda ignore-args
moby-foo)) ] tends to leak through abstractions and uglify the world.
I agree that this problem is one more of education and psychology.
However, it is a fundamental one. We would have the same problem if we
introduced (eq? #t '{}) as a notation where #\{ and #\} were allowed in
balanced pairs in place of #\( and #\).
I still see bugs in runtime-system code of the form shown above. My
experience agrees with others who find that "time and again, some subtle
bug, taking hours if not days to find"...
The history is that people have been burned badly enough to state:
"This certainly seems to be yet another opportunity to correct in Scheme
a fundamental mistake in Common Lisp."
The view of many people is that there is a problem here.
>> I see no problem with making disjointness of predicates BOOLEAN? and
>> NULL? in the IEEE Scheme Standard and allowing (e.g. Jinx) to redefine
>> BOOLEAN?, NULL?, LIST?, PAIR?, CONS, et cetera for idiosyncratic
>> purposes. As long as such *conventions* can be implemented in a standard
>> Scheme, there is no creative restriction and many people are saved from
>> needless confusion.
>>
>> I would be very interested in deep reasons why such confusion should be
>> mandated.
>>
>> Jinx, if you can explain to my simple self why you cannot redefine a
>> scheme implementation which follows the standard to do what you want in
>> this case, please do so. If not, I request that you remove your
>> objections.
>>
>> If I assume that () and #f will be eq? in all implementations and write my code
>> accordingly, I'm making a mistake. I should clearly use null? to detect ends
>> of lists EVEN THOUGH I KNOW THAT MY IMPLEMENTATION MAKES () AND #F EQUIVALENT,
>> but that's no reason that () and #F shouldn't be equivalent in some
>> implementations (for whatever reasons). After all, if I write
>>
>> (+ '(a b c) '(d e))
>>
>> to append two lists knowing that my implementation of Scheme defines + on both
>> numbers and lists, I shouldn't expect to get the right answer on other
>> implementations. The language should not have to clean up after careless
>> programmers, after all.
I typically work in a given week in at least 3 Scheme implementations [on
5 compute platforms under 4 OS's]. Last week I used T, Chez Scheme,
Gambit, ELK, and XScheme. I can't use I KNOW THAT MY IMPLEMENTATION...
I use other people's code. I am extremely interested in ultra-portable
bug-free code. My own experience is that (eq? #f '()) being #t works
against this.
I agree that a language should not have to clean up for careless
programmers. I should not have to fix `portable' code. But I do, time
and again. I would dearly love (if '() 1 2) to always evaluate to 1,
because it would save me much time.
------------------------------------------------------------------
>> To say that Jinx is doing this for "idiosyncratic
>> purposes" is just unfriendly.
I did not mean to imply that of Jinx. The intent was that *anyone* can
redefine the end-of-list marker in non-standard (~= idiosyncratic) ways
[I have used a function like moby-foo for just this purpose]. This was
assuming that (eq? #f '()) -> #f as a standard [which it currently is
not]. I apologize for the implication. If I did not think highly of
Jinx, I would not be trying to understand the reasons for his views [I
believe I do understand his position].
I am attempting to `do the right thing as I see it', not be unkind or
unfriendly. I don't always succeed. Sorry. (failure-continuation-?)
-Ken
∂15-Feb-90 0952 jeff%aiai.edinburgh.ac.uk@nsfnet-relay.ac.uk Re: disjointness of '() and #f
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 15 Feb 90 09:52:10 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA21625; Thu, 15 Feb 90 12:47:15 EST
Received: from NSFnet-Relay.AC.UK (nsfnet-relay.ac.uk) by zurich.ai.mit.edu; Thu, 15 Feb 90 12:46:13 est
Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK
via Janet with NIFTP id aa27303; 15 Feb 90 16:58 GMT
Date: Thu, 15 Feb 90 15:01:00 GMT
Message-Id: <7447.9002151501@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@nsfnet-relay.ac.uk>
Subject: Re: disjointness of '() and #f
To: arthur@zurich.ai.mit.edu
In-Reply-To: Arthur Gleckler's message of Wed, 14 Feb 90 23:09:58 est
Cc: scheme-standard@zurich.ai.mit.edu, rrrs-authors@zurich.ai.mit.edu
> Date: 14 Feb 90 15:38:08 PST (Wed)
> From: kend%mrloog.wr.tek.com@RELAY.CS.NET
>
> I would be very interested in deep reasons why such confusion should be
> mandated.
It's not mandated; it's allowed.
∂15-Feb-90 0958 jeff%aiai.edinburgh.ac.uk@nsfnet-relay.ac.uk Re: URGENT RESPONSE REQUESTED!!!!!
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 15 Feb 90 09:58:49 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA21708; Thu, 15 Feb 90 12:53:49 EST
Received: from NSFnet-Relay.AC.UK (nsfnet-relay.ac.uk) by zurich.ai.mit.edu; Thu, 15 Feb 90 12:52:50 est
Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK
via Janet with NIFTP id aa27372; 15 Feb 90 16:59 GMT
Date: Thu, 15 Feb 90 16:34:03 GMT
Message-Id: <7749.9002151634@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@nsfnet-relay.ac.uk>
Subject: Re: URGENT RESPONSE REQUESTED!!!!!
To: will%cs.uoregon.edu@nsfnet-relay.ac.uk, rrrs-authors@zurich.ai.mit.edu
In-Reply-To: will@edu.uoregon.cs's message of Wed, 14 Feb 90 14:38:51 PST
Cc: scheme-standard@zurich.ai.mit.edu
> Several voices in the scheme-standard list have begun to urge that
> the IEEE standard require #f and the empty list to be distinct.
> It is becoming clear that we will never again have the opportunity
> to make this change as painlessly as we can today.
This started with a proposal to add null? to the list of predicates
that specify disjoint types with an exception saying that () and #f
were allowed to be the same. A number of people took this as an
opportunity to say we should "go all the way" and require that ()
and #f be distinct. A couple of people (chiefly jinx) have objected.
It seems to me that we have had years in which to specify that () and
#f are distinct and haven't done so. There's been over a year in which
we could have had this discussion about the Scheme standard. I think
it's a bit unfair to bring it up again at the last minute and say,
in effect, "this is your last chance to Do It Right -- and you have to
do it NOW".
If objections to this proposal remain, I think it would be better to
follow normal procedures, delay the standard, and give everyone a
chance to come to a decision by consensus, which is the traditional
requirement for changing the Revised Report.
On the whole, I think it's more Scheme-like to make them distinct, but
I've often thought that this was basically an ideological/religious
dispute. Some people feel that null and false are distinct types and
that there's something wrong with having an object that belongs to
both, and other people don't, or else feel there's another, equally
valid, way to think of it. Many of the advocates of making #f and ()
distinct cite pragmatic reasons: subtle bugs occur or students will be
confused if () and #f can be the same. However, those on the other
side evidently don't agree. Thay don't say "you're right: there will
be lots of subtle bugs; but it's worth it".
Since I would find the pragmatic arguments more convincing, I would
like to see us at least reach agreement on whether or not _they_ are
correct.
-- Jeff
∂15-Feb-90 1040 @zurich.ai.mit.edu,@mc.lcs.mit.edu:hieb@iuvax.cs.indiana.edu Re: URGENT RESPONSE REQUESTED!!!!!
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 15 Feb 90 10:40:10 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA22291; Thu, 15 Feb 90 13:32:47 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Thu, 15 Feb 90 13:31:48 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa10125;
15 Feb 90 13:22 EST
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 15 Feb 90 13:21:50 EST
Received: from iuvax.cs.indiana.edu by mintaka.lcs.mit.edu id aa09938;
15 Feb 90 13:18 EST
Received: by iuvax.cs.indiana.edu
Date: Thu, 15 Feb 90 13:18:50 -0500
From: Robert Hieb <hieb@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: Re: URGENT RESPONSE REQUESTED!!!!!
Message-Id: <9002151318.aa09938@mintaka.lcs.mit.edu>
Yes, please make #f and '() distinct.
I am confused by Rozas' arguments. Can one really use any object one
damn well pleases as the empty list? I thought implementations were
constrained to use a unique object, which could be #f but could not be
#t, 0, etc. Given this strong constraint, it seems we might as well
distinguish '() from #f. Unless someone wishes to argue that this
remaining ambiguity is inherently useful...
∂15-Feb-90 1056 mkatz@garlic.stanford.edu '() and #f
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 15 Feb 90 10:56:37 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA22529; Thu, 15 Feb 90 13:45:30 EST
Received: from garlic.Stanford.EDU ([36.22.0.43]) by zurich.ai.mit.edu; Thu, 15 Feb 90 13:40:56 est
Received: by garlic.Stanford.EDU (5.57/Ultrix3.0-C)
id AA03541; Thu, 15 Feb 90 10:36:54 PST
Date: Thu, 15 Feb 90 10:36:54 PST
From: mkatz@garlic.stanford.edu (Morris Katz)
Message-Id: <9002151836.AA03541@garlic.Stanford.EDU>
To: rrrs-authors@zurich.ai.mit.edu
Cc: scheme-standard@zurich.ai.mit.edu
Subject: '() and #f
As one of the ones that seems to have engendered this huge argument/rift, I
would like to publicly appologize for starting this mess. I would like to make
a few (hopefully short) statements and then pul;l back from the fray.
1) I am personally willing to give up my effort to madate that '() and #f be
disjoint in the IEEE standard. However, I would STRONGLY urge that editors of
both RNRS and IEEE to include a footnote or comment to the effect that the
possibility of disjointness of these types in an implementation requires that
portable code guarantee that '() will never get used in a boolean context
(e.g., as the predicate in an IF).
2) I continue to strongly believe in the desirability of a disjoint type for
'() in Scheme and reserve the write to restart this argument at the next RNRS
meeting.
3) I agree with Daniel that only boolean values should be allowed in boolean
contexts. My earlier "(if '() a b) -> error" was actually a Freudian slip
which I backed off from because I did not want to broaden the argument at the
time. I DO believe that the above should be an error. I would advocate adding
not only NULL?, but also FALSE? and TRUE?, to Scheme (or maybe some successor
language). They would have the following definitions:
(define null? (lambda (a) (eqv? '() a)))
(define false? (lambda (a) (eqv? #f a)))
(define true? (lambda (a) (not (false? a))))
3a) Returning to another previous RNRS discussion, I would also restrict AND
and OR so that they would only operate on boolean values and would be return
boolean values. I believe that the function of AND and OR on non-booleans
should be achieved using IF and appropriate abstration (if desired) with
macros. [Yes, I do remember that we don't yet have macros, but I am still
hoping!]
-------------------------------------------------------------------------------
Morry Katz
katz@cs.stanford.edu
-------------------------------------------------------------------------------
∂15-Feb-90 1057 @zurich.ai.mit.edu,@RELAY.CS.NET,@tektronix.tek.com:kend@mrloog.wr.tek.com Re: disjointness of '() and #f
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 15 Feb 90 10:57:25 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA22616; Thu, 15 Feb 90 13:51:50 EST
Received: from RELAY.CS.NET (relay.cs.net) by zurich.ai.mit.edu; Thu, 15 Feb 90 13:50:51 est
Received: from tektronix.tek.com by RELAY.CS.NET id aa15940; 15 Feb 90 12:50 EST
Received: by tektronix.TEK.COM (5.51/7.1)
id AA21936; Thu, 15 Feb 90 10:54:05 PST
Received: by wrgate.wr.tek.com (5.51/7.1)
id AA19796; Thu, 15 Feb 90 10:50:22 PST
Received: by mrloog.WR.TEK.COM (1.2/7.1)
id AA21520; Thu, 15 Feb 90 10:39:18 pst
Message-Id: <9002151839.AA21520@mrloog.WR.TEK.COM>
To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@nsfnet-relay.ac.uk>
Cc: arthur@zurich.ai.mit.edu, scheme-standard@zurich.ai.mit.edu,
rrrs-authors@zurich.ai.mit.edu, kend@mrloog.wr
Subject: Re: disjointness of '() and #f
In-Reply-To: Your message of Thu, 15 Feb 90 15:01:00 GMT.
<7447.9002151501@subnode.aiai.ed.ac.uk>
Date: 15 Feb 90 10:39:10 PST (Thu)
From: kend%mrloog.wr.tek.com@relay.cs.net
>> > Date: 14 Feb 90 15:38:08 PST (Wed)
>> > From: kend%mrloog.wr.tek.com@RELAY.CS.NET
>> >
>> > I would be very interested in deep reasons why such confusion should be
>> > mandated.
>>
>> From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@nsfnet-relay.ac.uk>
>>
>> It's not mandated; it's allowed.
The sad fact is that *allowing* something in a standard *mandates* it on
all users--who *must* be aware of a *potential* behavior.
-Ken
∂15-Feb-90 1138 ramsdell@linus.mitre.org the next RNRS meeting
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 15 Feb 90 11:37:27 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA23401; Thu, 15 Feb 90 14:33:06 EST
Received: from linus.mitre.org ([129.83.100.103]) by zurich.ai.mit.edu; Thu, 15 Feb 90 14:32:09 est
Received: from huxley.mitre.org by linus.mitre.org (5.61/RCF-4S)
id AA11096; Thu, 15 Feb 90 14:29:46 -0500
Posted-Date: Thu, 15 Feb 90 14:29:43 EST
Received: by huxley.mitre.org (5.61/RCF-4C)
id AA03949; Thu, 15 Feb 90 14:29:44 -0500
From: ramsdell@linus.mitre.org
Message-Id: <9002151929.AA03949@huxley.mitre.org>
To: rrrs-authors@zurich.ai.mit.edu
Subject: the next RNRS meeting
In-Reply-To: Your message of Thu, 15 Feb 90 10:36:54 -0800.
<9002151836.AA03541@garlic.Stanford.EDU>
Date: Thu, 15 Feb 90 14:29:43 EST
>> 2) I continue to strongly believe in the desirability of a disjoint type for
>> '() in Scheme and reserve the write to restart this argument at the next RNRS
>> meeting.
Given Jinx's clear statements, I am not sure about the merits of
restarting this argument at the next RNRS meeting. I think there are
other issues that could be profitably discussed. The two topics I
have in mind are multiple value returns and records. I propose that
we schedule a meeting for some time this year. I suggest the next RNRS
meeting be held in White Plains, NY at the SIGPLAN'90 conference in
late June.
John
∂15-Feb-90 1156 jinx@zurich.ai.mit.edu URGENT RESPONSE REQUESTED!!!!!
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 15 Feb 90 11:56:37 PST
Received: from zurich.ai.mit.edu ([18.43.0.171]) by life.ai.mit.edu (4.0/AI-4.10) id AA23758; Thu, 15 Feb 90 14:52:08 EST
Received: from localhost by zurich.ai.mit.edu; Thu, 15 Feb 90 14:51:25 est
Date: Thu, 15 Feb 90 14:51:25 est
From: jinx@zurich.ai.mit.edu (Guillermo J. Rozas)
Message-Id: <9002151951.AA07003@zurich.ai.mit.edu>
To: hieb@iuvax.cs.indiana.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Robert Hieb's message of Thu, 15 Feb 90 13:18:50 -0500 <9002151318.aa09938@mintaka.lcs.mit.edu>
Subject: URGENT RESPONSE REQUESTED!!!!!
Reply-To: jinx@zurich.ai.mit.edu
I am confused by Rozas' arguments. Can one really use any object one
damn well pleases as the empty list? I thought implementations were
constrained to use a unique object, which could be #f but could not be
#t, 0, etc. Given this strong constraint, it seems we might as well
distinguish '() from #f. Unless someone wishes to argue that this
remaining ambiguity is inherently useful...
Yet another point where you and I have different points of view. I
don't believe that disjointness is necessary, interesting, or
aesthetically pleasing (obviously to me). Although it is true that
the reports currently explicitly allow #f to be '(), they do not
preclude '() from being any other object, since null? is not in the
list of disjoint type predicates. Thus it is legal for '() to be a
pair? or a number?, although it can't be both. This is precisely the
nature of the requested modification to the draft standard with which
I disagree.
I'm actually somewhat surprised by your position on this. I had
viewed you as one of the few other people in the community that was
worried about lists being so ingrained in the language.
Assuming that at some point in the future we were able to disentangle
application (apply and rest parameters) from lists, lists (including
'()) could become library routines, not even present by default in
some implementations.
The requirement that '() be disjoint from all other objects precludes
portable implementations of the list routines that "patch" the
reader to add '(), since there is no portable way of creating disjoint
types.
The goal towards which scheme should grow (in my "distorted"
aesthetics) is to have very few built-in procedures and data
types/structures, but have good enough abstraction facilities that
even lists and numbers can be implemented portably and efficiently.
Thus adding to the disjointness of types only forces more and more
"extraneous objects" to exist in my ideal dialect, complicating it.
∂15-Feb-90 1159 jinx@zurich.ai.mit.edu disjointness of '() and #f
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 15 Feb 90 11:59:42 PST
Received: from zurich.ai.mit.edu ([18.43.0.171]) by life.ai.mit.edu (4.0/AI-4.10) id AA23785; Thu, 15 Feb 90 14:53:29 EST
Received: from localhost by zurich.ai.mit.edu; Thu, 15 Feb 90 14:52:46 est
Date: Thu, 15 Feb 90 14:52:46 est
From: jinx@zurich.ai.mit.edu (Guillermo J. Rozas)
Message-Id: <9002151952.AA07013@zurich.ai.mit.edu>
To: kend%mrloog.wr.tek.com@relay.cs.net
Cc: arthur@zurich.ai.mit.edu, scheme-standard@zurich.ai.mit.edu,
rrrs-authors@zurich.ai.mit.edu, kend@mrloog.wr
In-Reply-To: kend%mrloog.wr.tek.com@RELAY.CS.NET's message of 15 Feb 90 09:41:07 PST (Thu) <9002151741.AA20666@mrloog.WR.TEK.COM>
Subject: disjointness of '() and #f
Reply-To: jinx@zurich.ai.mit.edu
This is a frequent source of confusion in data structures where 2 pieces
of information is desired: (1) was an action successful? (2) if
successful, what was the value of the result? [multiple value returns is
another discussion]. As (2) is only interesting in the success case, the
attempt is made to overload the returned value for two uses. E.g.
(let ( (probe (table-lookup table key)) )
(if probe
(success-action probe)
(failure-action)
) )
This works as long as the value of PROBE is #f XOR a valid data value.
What happens when key is in the table, and its associated value is #f?
You don't remove the problem by mandating (eq? #f '()) to be #f, you
have just hidden one instance of it. The real problem is #f, not '().
∂15-Feb-90 1215 jinx@zurich.ai.mit.edu #f, '(), and true radicalism.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 15 Feb 90 12:15:35 PST
Received: from zurich.ai.mit.edu ([18.43.0.171]) by life.ai.mit.edu (4.0/AI-4.10) id AA23991; Thu, 15 Feb 90 15:04:26 EST
Received: from localhost by zurich.ai.mit.edu; Thu, 15 Feb 90 14:59:52 est
Date: Thu, 15 Feb 90 14:59:52 est
From: jinx@zurich.ai.mit.edu (Guillermo J. Rozas)
Message-Id: <9002151959.AA07026@zurich.ai.mit.edu>
To: daniel@mojave.stanford.edu
Cc: will@cs.uoregon.edu, rrrs-authors@zurich.ai.mit.edu,
scheme-standard@zurich.ai.mit.edu
In-Reply-To: Daniel Weise's message of Thu, 15 Feb 90 07:55:05 PST <9002151555.AA27317@mojave.Stanford.EDU>
Subject: #f, '(), and true radicalism.
Reply-To: jinx@zurich.ai.mit.edu
I care more about truth and falsity than about the list termination
conventions. To me the question is how IF treats its predicate value.
As long as a predicate of '() and #f mean take the false branch, and
all other values mean take the true branch, there will be horrible
punning and accidentally unportable code.
The current draft of the standard states
Of all the standard Scheme values, only #f is guaranteed to count as
false in conditional expressions. It is not specified whether the
empty list counts as false or as true in conditional expressions.
Except for #f and possibly the empty list, all standard Scheme values,
including #t, pairs, ..., count as true.
Thus it is legal for an implementation to have '() count as true.
Thus portable code CANNOT use the pun.
I don't want '() to count as #f, unless they are the same object. I
just think that the decision of chosing a value to represent the empty
list should be orthogonal to the decision of chosing a value to
represent falsity, and they may very well be the same.
Perhaps people would be happier if the wording were modified to say
something like
"Only #f is considered to be false. In some implementations the empty
list may be the same object as #f, and thus in these implementations
'() will be considered false as well."
It seems silly (although I don't find it objectionable) to have
implementations where '() and #f are distinct yet they are both false.
This should certainly not be required.
∂15-Feb-90 1218 KMP@stony-brook.scrc.symbolics.com URGENT RESPONSE REQUESTED!!!!!
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 15 Feb 90 12:18:26 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA24159; Thu, 15 Feb 90 15:14:07 EST
Received: from STONY-BROOK.SCRC.Symbolics.COM (stony-brook.scrc.symbolics.com) by zurich.ai.mit.edu; Thu, 15 Feb 90 15:13:15 est
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 744233; 15 Feb 90 14:34:59 EST
Date: Thu, 15 Feb 90 14:34 EST
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Subject: URGENT RESPONSE REQUESTED!!!!!
To: will@cs.uoregon.edu
Cc: rrrs-authors@zurich.ai.mit.edu, scheme-standard@zurich.ai.mit.edu
In-Reply-To: <9002142238.AA27288@spencer.cs.uoregon.edu>
Message-Id: <19900215193454.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
For the record, here is my position on #f and () ...
I strongly support any resolution to this controversy which leaves all
implementations required to do the same thing. I believe it is a grave
mistake to leave this aspect of the language unspecified.
It is my strong belief that -either- the language should accept only
true or false as truth values (hence negating the concept of `predicates
with useful return values like MEMBER') -or- the language should have
(either explicitly or implicitly) a true-p predicate which is defined on
every object in a portable way. Truthity/falsity are so fundamental a
concept in a computer language that it is a severe mistake to leave this
issue an open one.
It will be a major ongoing source of portability problems if you
standardize on making either behavior permissible. While there may be
some people hurt by the change in the nearterm, the longterm benefit of
having the entire community agree and letting them get on to disputing
more important matters will be worth it.
In fact, I do not believe there is a definite right or wrong in this.
I can see value in both positions.
The ability to `pun' on false/empty is, at times, valuable and not
without merit. However, if this pun is not portably available, it is a
dangerous weapon because puns are subtle and easy to overlook in a
porting process.
Likewise, the ability to speak unambiguously is also, at times, a value
tool. So I can respect a decision to make these two separate.
My overriding feeling as I continue to monitor the Lisp and Scheme design
discussions is that a characteristic property of Lisp (that distinguishes
it from Scheme) is a willingness to permit considerably more punning than
the Scheme community would feel comfortable with.
Consequently, while I would probably argue strongly that CL should maintain
this ambiguity in a portable fashion (and I disagree with GLS that this
is a clear mistake), I do agree with what appears to me to be tha majority
of those in the Scheme community that the right thing for Scheme is to
eliminate this ability to have an ambiguity on this issue.
Finally, I note that it's hard to undo something once it makes it into a
standard, and I really think that if you're gonna ultimately do it (and
the Scheme community--even some of those who oppose the change at this time--
seems to see itself in transition toward ultimately doing it), doing it
before you standardize is an exceptionally good thing to do. It's one less
frame to keep on the continuation `stack' for the design of Scheme--one
less thing to have to remember to do the next time around.
Ok, so the last paragraph wasn't final, one more point: I think a standard
is more powerful if it really achieves consensus. If you really don't agree
on something and so you write the disagreement into the standard, then you
confuse and irritate people who think that `adhering to the standard' means
that your code runs portably. Users of CL found this out in spades the hard
way. The more things you can out-and-out agree upon, the stronger a position
your standard will have. So this is yet another reason to agree to agree.
My position in summary:
- I strongly support making #f and () required to be distinct objects.
- I would happily support making #f and () required to be EQ objects
as a fall-back.
- I strongly oppose any wording permitting implementations to diverge
on this issue.
∂15-Feb-90 1353 mkatz@garlic.stanford.edu the next RNRS meeting
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 15 Feb 90 13:53:19 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA25805; Thu, 15 Feb 90 16:51:02 EST
Received: from garlic.Stanford.EDU ([36.22.0.43]) by zurich.ai.mit.edu; Thu, 15 Feb 90 16:49:37 est
Received: by garlic.Stanford.EDU (5.57/Ultrix3.0-C)
id AA04399; Thu, 15 Feb 90 13:45:19 PST
Date: Thu, 15 Feb 90 13:45:19 PST
From: mkatz@garlic.stanford.edu (Morris Katz)
Message-Id: <9002152145.AA04399@garlic.Stanford.EDU>
To: ramsdell@linus.mitre.org
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: ramsdell@linus.mitre.org's message of Thu, 15 Feb 90 14:29:43 EST <9002151929.AA03949@huxley.mitre.org>
Subject: the next RNRS meeting
Posted-Date: Thu, 15 Feb 90 14:29:43 EST
From: ramsdell@linus.mitre.org
Date: Thu, 15 Feb 90 14:29:43 EST
>> 2) I continue to strongly believe in the desirability of a disjoint type for
>> '() in Scheme and reserve the write to restart this argument at the next RNRS
>> meeting.
Given Jinx's clear statements, I am not sure about the merits of
restarting this argument at the next RNRS meeting. I think there are
other issues that could be profitably discussed. The two topics I
have in mind are multiple value returns and records.
Unfortunately, a similar argument could be made that discussing these topics is
also pointless because of strong opinions on these issues as well. Personally,
I would like to discuss all 3 of the issues presented in the future.
I propose that
we schedule a meeting for some time this year. I suggest the next RNRS
meeting be held in White Plains, NY at the SIGPLAN'90 conference in
late June.
What percentage of the Scheme community is planning on attending this
conference? I know that I personally will NOT be attending.
-------------------------------------------------------------------------------
Morry Katz
katz@cs.stanford.edu
-------------------------------------------------------------------------------
∂15-Feb-90 1356 @zurich.ai.mit.edu,@RELAY.CS.NET,@tektronix.tek.com:kend@mrloog.wr.tek.com Re: disjointness of '() and #f
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 15 Feb 90 13:56:02 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA25768; Thu, 15 Feb 90 16:49:27 EST
Received: from RELAY.CS.NET (relay.cs.net) by zurich.ai.mit.edu; Thu, 15 Feb 90 16:48:32 est
Received: from tektronix.tek.com by RELAY.CS.NET id aa19944; 15 Feb 90 15:42 EST
Received: by tektronix.TEK.COM (5.51/7.1)
id AA28235; Thu, 15 Feb 90 13:39:16 PST
Received: by wrgate.wr.tek.com (5.51/7.1)
id AA22791; Thu, 15 Feb 90 13:35:32 PST
Received: by mrloog.WR.TEK.COM (1.2/7.1)
id AA23988; Thu, 15 Feb 90 13:30:19 pst
Message-Id: <9002152130.AA23988@mrloog.WR.TEK.COM>
To: jinx@zurich.ai.mit.edu
Cc: kend%mrloog.wr.tek.com@relay.cs.net, arthur@zurich.ai.mit.edu,
scheme-standard@zurich.ai.mit.edu, rrrs-authors@zurich.ai.mit.edu,
kend@mrloog.wr, kend@mrloog.wr
Subject: Re: disjointness of '() and #f
In-Reply-To: Your message of Thu, 15 Feb 90 14:52:46 est.
<9002151952.AA07013@zurich.ai.mit.edu>
Date: 15 Feb 90 13:30:00 PST (Thu)
From: kend%mrloog.wr.tek.com@relay.cs.net
>>
>> This is a frequent source of confusion in data structures where 2 pieces
>> of information is desired: (1) was an action successful? (2) if
>> successful, what was the value of the result? [multiple value returns is
>> another discussion]. As (2) is only interesting in the success case, the
>> attempt is made to overload the returned value for two uses. E.g.
>>
>> (let ( (probe (table-lookup table key)) )
>> (if probe
>> (success-action probe)
>> (failure-action)
>> ) )
>>
>> This works as long as the value of PROBE is #f XOR a valid data value.
[JINX]
>>
>> What happens when key is in the table, and its associated value is #f?
>> You don't remove the problem by mandating (eq? #f '()) to be #f, you
>> have just hidden one instance of it. The real problem is #f, not '().
I was pointing out a problem which I often see. The implicit assumptions
were given as:
[A] "Never use #f in a data context, only in a control context".
[B] This works as long as the value of PROBE is #f XOR a valid data value.
]My only observation is that a multiple value return is useful to me
here.[
There are other symptoms e.g. [someone else mad at me--sorry], in T's 3.1
runtime (make-vector 5 '()) -> #(0 0 0 0 0). It was easy to fix this to
return the proper #(() () () () ()). It happened to break assumptions in
the program I was working on, but it code me an hour or two [OK, I'm
slow].
There are just too many cases of this same oversight.
-Ken
∂16-Feb-90 1157 @zurich.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu Re: URGENT RESPONSE REQUESTED!!!!!
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 16 Feb 90 11:57:22 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA03260; Fri, 16 Feb 90 14:55:01 EST
Received: from skinner.cs.uoregon.edu (skinner.cs.uoregon.edu) by zurich.ai.mit.edu; Fri, 16 Feb 90 14:51:24 est
Received: from spencer.cs.uoregon.edu by skinner.cs.uoregon.edu with SMTP
(5.61.14/IDA-1.2.8) id AA07158; Fri, 16 Feb 90 11:50:26 -0800
Received: by spencer.cs.uoregon.edu; Fri, 16 Feb 90 11:52:29 PST
Date: Fri, 16 Feb 90 11:52:29 PST
From: will@cs.uoregon.edu
Message-Id: <9002161952.AA08207@spencer.cs.uoregon.edu>
To: rrrs-authors@zurich.ai.mit.edu
Subject: Re: URGENT RESPONSE REQUESTED!!!!!
That was fun, wasn't it? Thanks to all who responded to my urgent
call for opinion.
Peace, Will
∂16-Feb-90 1651 jeff%aiai.edinburgh.ac.uk@nsfnet-relay.ac.uk Re: URGENT RESPONSE REQUESTED!!!!!
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 16 Feb 90 16:51:12 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA02156; Fri, 16 Feb 90 13:48:36 EST
Received: from NSFnet-Relay.AC.UK (nsfnet-relay.ac.uk) by zurich.ai.mit.edu; Fri, 16 Feb 90 13:47:15 est
Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK
via Janet with NIFTP id aa27477; 16 Feb 90 17:38 GMT
Date: Fri, 16 Feb 90 17:21:48 GMT
Message-Id: <12120.9002161721@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@nsfnet-relay.ac.uk>
Subject: Re: URGENT RESPONSE REQUESTED!!!!!
To: will%cs.uoregon.edu@nsfnet-relay.ac.uk
Cc: rrrs-authors@zurich.ai.mit.edu, scheme-standard@zurich.ai.mit.edu
I think it's important to keep two keep separate the issue of whether
'() and #f are distinct and the issue of whether any values other than
#t can count as true. I don't mind having #f and '() distinct, but
I do not want Scheme to change so that only #t is true. There are
many cases in which it is possible to pick one value to indicate
failure (even though there are also cases in which it is not), and
it is very helpful if that value counts as false. It's not just a
question of IF, AND, and OR; a whole style of programming can be
made to seem wrong.
∂16-Feb-90 1651 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #302
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 16 Feb 90 16:51:42 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA01658; Fri, 16 Feb 90 13:26:36 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Fri, 16 Feb 90 13:25:38 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa05481;
16 Feb 90 12:48 EST
Message-Id: <DIGEST.184.900216.121357.3@MC.LCS.MIT.EDU>
Date: 16 Feb 90 12:13:57 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #302
Scheme Digest #302 16 Feb 90 12:13:57 EST
Today's Topics:
XSCHEME Status?
I need a Scheme
Scheme docs in PostScript?
Fast Scheme for Suns?
Functional / algebraic languages for DS3100
address for ftping T
----------------------------------------------------------------------
Message-ID: <16174@well.sf.ca.us>
Date: 14 Feb 90 23:05:36 GMT
From: Jordan Bortz <bu.edu!snorkelwacker!apple!well!frobozz@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: XSCHEME Status?
Can someone please fill me in on the status of XSCHEME?
Is it available for the Mac? What about for those
of us without anon FTP?
Thanks,
Jordan
--
***********************************************************************
* Jordan A. Bortz, Higher Level Software, Santa Cruz, CA *
* well!frobozz frobozz@well.sf.ca.us 408 - 476 - 8464 *
***********************************************************************
------------------------------
Message-ID: <1990Feb15.061211.6113@agate.berkeley.edu>
Date: 15 Feb 90 06:12:11 GMT
From: Hurley Braden <agate!web-1c!c60a-1gt@ucbvax.berkeley.edu>
To: scheme@MC.lcs.mit.edu
Subject: I need a Scheme
< eat me >
Howdy,
I was wondering if anyone out there knows if there is a Scheme
for the Amiga (brand tm, copyright etc ...).
Oh, and since I am a lowly student (read poor (strike that very
poor)) I was wondering if there is a PD version hanging around
somewhere.
thanks in advance.
Hurley.
"Me against the Universe," I said.
"With those odds, even a loser can look good."
------------------------------
Message-ID: <17020001@hpdml93.HP.COM>
Date: 14 Feb 90 21:03:21 GMT
From: Steve Ritacco <hp-ses!hpdml93!sritacco@hplabs.hpl.hp.com>
To: scheme@MC.lcs.mit.edu
Subject: Scheme docs in PostScript?
Hi,
I have built the 7.0 Scheme system for my machine, but I'm
having trouble creating the documentation. Does anyone have
a PostScript version I could just print out? This would
save me a major headache.
Thanks
------------------------------
Message-ID: <9002151449.AA26625@NEBULA.SUN3.CS.YALE.EDU>
Date: Thu, 15 Feb 90 09:58:28 EST
From: Duke Briscoe <briscoe-duke@YALE.EDU>
To: scheme@mc.lcs.mit.edu
Subject: Re: Fast Scheme for Suns?
The T language includes an environment for Scheme, and from my
experience I judge it to be at least 99% conformant to the Scheme
standard, and there isn't any performance penalty for using T to run
Scheme since the Scheme environment just allows a different set of
names to be used for the underlying T functions. T also provides some
useful extensions to Scheme. T has an optimizing compiler, and best
of all it is available by anonymous ftp from trix.ai.mit.edu in the
pub/t3.1 directory. That directory contains binaries and sources for
T3.1. Currently available versions are for Dec3100(pmax),
Sun4(sparc),Sun3, Vax/Unix, Encore, Hp workstation, Apollo and
Mac/Aux. The online version of the T manual is also there as well as
release notes for T3.0 and T3.1. For Sun and Vax there is a C/Unix
interface to T.
From masala.lcs.mit.edu you can get a T dialect extended for
parallelism (uses the future construct) called Mul-T; it runs on the
Encore Multimax.
-------
------------------------------
Message-ID: <9002151510.AA26799@NEBULA.SUN3.CS.YALE.EDU>
Date: Thu, 15 Feb 90 10:18:37 EST
From: Duke Briscoe <briscoe-duke@YALE.EDU>
To: scheme@mc.lcs.mit.edu
Subject: re: Functional / algebraic languages for DS3100
John Baugh writes:
>Apparently NJML is soon to be released for the pmax. My
>question is `Are there any (currently available) alternatives?'
>By alternatives I mean a `modern' functional language with
>disjoint union data constructors, pattern matching, etc.
>I heard that a scheme-based interpreter exists for Haskell--is
>that true? If so, would it run on T (using the scheme mode)?
The Yale Haskell system is planned to be released in a few weeks. It
compiles Haskell to T, which then can be compiled by the T Orbit
compiler. The Yale Haskell system is not an interpreter, but we are
working on a user interface which will allow something similar to a
read-eval-print loop. Actually, it will be more of a read-(compile
Haskell to T)-run-print loop.
T's scheme-mode has nothing to do with Haskell, although you could
interface T code or T scheme-mode code to Haskell code. You could
even make use of the T Unix/C foreign function interface. I think
someone at Yale has recently linked some of the X window system into
T, although I haven't seen it running.
We'll announce the Haskell release to this list when it is ready in a
few weeks. It will be available by anonymous ftp.
Duke
-------
------------------------------
Message-ID: <9002151924.AA28390@NEBULA.SUN3.CS.YALE.EDU>
Date: Thu, 15 Feb 90 14:33:14 EST
From: Duke Briscoe <briscoe-duke@YALE.EDU>
To: scheme@mc.lcs.mit.edu
Subject: re: address for ftping T
It has come to my attention that some people have trouble with the
hostname TRIX.AI.MIT.EDU. That is where my earlier note said the T
files are available for anonymous ftp. The numeric Internet address
for trix is 128.52.32.6. You could also try wheaties.ai.mit.edu
which also has the files. I think peoples host tables are more likely
to have wheaties than trix, so wheaties may work for you while trix
wouldn't. In fact, this was true for my own workstation.
Duke
-------
------------------------------
End of Scheme Digest
********************
∂16-Feb-90 1654 @zurich.ai.mit.edu,@mc.lcs.mit.edu,@ZERMATT.lcs.mit.edu:ziggy@hx.lcs.mit.edu Tentative Proposal: '() vs #F
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 16 Feb 90 16:54:31 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA02584; Fri, 16 Feb 90 14:17:20 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Fri, 16 Feb 90 14:16:20 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa07891;
16 Feb 90 13:34 EST
Received: from ZERMATT.LCS.MIT.EDU (CHAOS 17316) by MC.LCS.MIT.EDU; 16 Feb 90 13:25:20 EST
Received: from RTS-8.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via CHAOS with SMTP id 11847; 16 Feb 90 00:51:50 EST
Message-Id: <2844136293-1505379@RTS-8>
Sender: ziggy@rts-8.lcs.mit.edu
Date: Fri, 16 Feb 90 00:51:33 EST
Reply-To: ziggy@hx.lcs.mit.edu
From: "Michael R. Blair" <ziggy@hx.lcs.mit.edu>
To: rrrs-authors@zermatt.lcs.mit.edu
Subject: Tentative Proposal: '() vs #F
Regarding for the '() vs #F stuff, I agree with the sentiment that IF et al
should be unspecified for non-boolean test expressions (I tend to be a type
freak) but I concur with Jinx's position that the list termination object is
(and should be) arbitrary.
I find it intriquing to consider introducing a new distinguished object
#!END-OF-LIST (which presumably satisfies EOL-OBJECT? but not NULL?) so that
for example (CONS '() '()) will print like ( () . () ), which gives me nice
external represention for (say) binary trees implemented as (LEFT . RIGHT)
pairs. This is of type (PAIROF NULL NULL) and *not* of type (LISTOF NULL)
since (LISTOF NULL) is a widget that terminates in #!%END-OF-LIST (you know,
that invisible ". ()" which traditional PRINTers dont print). I then could
distinguish PAIRs from LISTs as follows:
(x . y) is of type PAIR iff y is not #!%*END-OF-LIST
(x . y) is of type LIST iff y is either a LIST or #!%*&END-OF-LIST
() is an honorary (distinguished) LIST which is also NULL; it is the unique
object which NULL? recognizes and respects. It is *not* a PAIR.
#!%*&↑END-OF-LIST is a distinguished object whose type is THE-END-OF-LIST and
which is distinct from all other types. It really need not have an enternal
represenation (since presumably we like our PRINTERs to suppress printing it
anyway, just as we dont want to have to type it in our input). It's type
predicate is named EOL-OBJECT? which is of the same stature as EOF-OBJECT?
(with respect to the END-OF-FILE object ).
All this is to say that:
- I like booleans as distinct types
- I like '() to denote "The Empty List" [i.e. (NULL? '()) ==> #T ]
- I like making a distinction between "The Empty List" and "The End Of List"
(they just happen to be the same in "traditional" Lisps... which is
to say that they identify "The Empty List" as the list which
contains only "The End Of List" object).
- I like (in view of the above) to distinguish the BOOLEAN? objects [viz. #T
and #F] from the NULL? object [viz. '() ] from the EOL-OBJECT?
object [viz. <it has no name>]
- I like to think that (CONS x '()) is a PAIR (not a list) whereas (LIST x)
is a LIST *and* a PAIR.
(Note that if the EOL-OBJECT? object were to have an external
represenation then we could say that (CONS x #u) = (LIST x) ...
where I use #u to annotate the unit type EOL-OBJECT? which has only
itself as member, but I am sure ever reader has a far better
represenation in mind... like #<fnord>)
To summarize:
"BOOLEs are BOOLEs and
NULLs are NULLs and
EOLs are EOLs and
never the thwain shall meet" ["thwain" = (1+ "twain") in Lithp ?]
Pedagogically, I think this is cleaner than the traditional NULL=EOL pun.
Consider this to be a tentative proposal. That is, have I just taken the
cowards way out by saying "Let's introduce yet another gratuitous distinguished
object/type" or do you feel this actually has merit?
~Ziggy
∂17-Feb-90 0418 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #303
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 17 Feb 90 04:17:57 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA14980; Sat, 17 Feb 90 07:14:59 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Sat, 17 Feb 90 07:13:12 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa18597;
17 Feb 90 7:02 EST
Message-Id: <DIGEST.184.900217.061845.10@MC.LCS.MIT.EDU>
Date: 17 Feb 90 06:18:44 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #303
Scheme Digest #303 17 Feb 90 06:18:44 EST
Today's Topics:
Need Scheme R3RS Spec.
Lisp and Functional Programming Conference '90 (very long)
----------------------------------------------------------------------
Message-ID: <MAC.90Feb15144139@k9.cad.mcc.com>
Date: 15 Feb 90 20:41:39 GMT
From: Mac Michaels <zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!milano!cadillac!mac@think.com>
To: scheme@MC.lcs.mit.edu
Subject: Need Scheme R3RS Spec.
I have been watching this group for a couple of weeks now hoping to see
a hint to answer a question that is probably common knowledge.
I am analyzing Scheme and Common Lisp to try to determine which will best
suit the needs of the Computer Aided Engineering (CAE) community. I need
to get a copy of the Scheme R3RS specification. Where is a location that
has it available for anonymous ftp or someone who can email it to me?
Please contact me before emailing as I don't want to waste internet
bandwidth getting many copies. I am also interested in the R4RS draft if
it is available.
--
USPS: Mac Michaels, 3500 West Balcones Center Dr., Austin,TX 78759
ARPA: mac@mcc.com
UUCP: {uunet,harvard,gatech,pyramid}!cs.utexas.edu!milano!cadillac!mac
:-)))))))) She had so many chins, she looked like a piece of Lisp code!
------------------------------
Message-ID: <540@mirsa.inria.fr>
Date: 15 Feb 90 12:26:08 GMT
From: Gilles Kahn <mcsun!inria!mirsa!falbala!kahn@uunet.uu.net>
To: scheme@mc.lcs.mit.edu
Subject: Lisp and Functional Programming Conference '90 (very long)
1990 Lisp and Functional Programming
Conference
Advance Program
Nice, France, June 27--29, 1990
A conference jointly sponsored by the ACM Special Interest Groups
SIGPLAN, SIGACT and SIGART, in cooperation with SIGSAM. The conference
is organized in France in cooperation with INRIA.
Tuesday, June 26th
05:00--06:30 pm Conference Registration
05:00--06:30 pm Reception
Wednesday, June 27th
09:00--10:30 Session 1: Chaired by Christopher T. Haynes, Indiana University
Andrew P. Tolmach and Andrew W. Appel, Princeton University
Debugging Standard ML Without Reverse Engineering
Pavel Curtis, Xerox PARC, and James Rauen, MIT
A Module System for Scheme
Mark A. Sheldon and David K. Gifford, MIT
Static Dependent Types for First Class Modules
11:00--12:30 Session 2: Chaired by Pierre-Louis Curien, ENS Paris
Luca Cardelli, DEC SRC, and Giuseppe Longo, University of Pisa and LIENS
A Semantic Basis for Quest
V. Breazu-Tannen, C. A. Gunter, A. Scedrov, University of Pennsylvania
Computing with Coercions
Philip Wadler, University of Glasgow
Comprehending Monads
02:00--03:30 Session 3: Chaired by Robert Kessler, University of Utah
Douglas Johnson, Texas Instruments
Trap Architectures for Lisp Systems
Benjamin Zorn, Berkeley
Comparing Mark-and-Sweep and Stop-and-Copy Garbage Collection
Gregor Kiczales, Xerox PARC, and Luis Rodriguez, MIT
Efficient Method Dispatch in PCL
04:00--06:00 Session 4: Chaired by Hal Abelson, MIT
Chris Hanson, MIT
Efficient Stack Allocation for Tail-Recursive Languages
Marc Feeley and James S. Miller, Brandeis University
A Parallel Virtual Machine for Efficient Scheme Compilation
Clifford Walinsky and Deb Banerjee, Dartmouth College
A Functional Programming Language Compiler for Massively Parallel Computers
Andrew Berlin, MIT
Partial Evaluation Applied to Numerical Computation
Thursday, June 28th
09:00--10:30 Session 5: Chaired by Hans-J. Boehm, Xerox PARC
Olivier Danvy, Indiana University, and Andrzej Filinski, Carnegie-Mellon
Abstracting Control
Dorai Sitaram and Matthias Felleisen, Rice University
Reasoning with Continuations II: How to Get Full Abstraction for
Models of Control
Morry Katz and Daniel Weise, Stanford University
Continuing Into the Future: On the Interaction of Futures and
First-Class Continuations
11:00--12:30 Session 6: Chaired by John Foderaro, Franz, Inc.
E. Mohr, Yale University, D. A. Kranz, MIT, and R. H. Halstead Jr., DEC CRL
Lazy Task Creation: A Technique for Increasing the Granularity of
Parallel Programs
Randy B. Osborne, DEC CRL
Speculative Computation in Multilisp
J.F. Giorgi and D. Le M\'etayer, IRISA/INRIA
Continuation-Based Parallel Implementation of Functional Programming
Languages
02:00--03:30 Session 7: Chaired by Paul Hudak, Yale University
Henry G. Baker, Nimble Computer Corporation
Unify and Conquer (Garbage, Updating, Aliasing, ...) in Functional
Languages
G.L. Burn, Imperial College
Using Projection Analysis in Compiling Lazy Functional Programs
M. Draghicescu and S. Purushothaman, Pennsylvania State University
A Compositional Analysis of Evaluation-order and Its Application
04:00--05:30 Session 8: Chaired by Simon Peyton-Jones, University of Glasgow
Hanne Riis Nielson and Flemming Nielson, Aarhus University
Context Information for Lazy Code Generation
Charles Consel, Yale University
Binding Time Analysis for Higher Order Untyped Functional Languages
Laurence Puel, LIENS and DEC PRL, and Ascander Suarez, DEC PRL
Compiling Pattern Matching by Term Decomposition
Friday, June 29th
08:30--10:00 Session 9: Chaired by Mitchell Wand, Northeastern University
Carsten K. Gomard, University of Copenhagen
Partial Type Inference for Untyped Functional Programs
Daniel Leivant, Carnegie Mellon University
Discrete Polymorphism
Brian T. Howard and John C. Mitchell, Stanford University
Operational and Axiomatic Semantics of PCF
10:30--12:30 Session 10: Chaired by Ken McAloon, Brooklyn College
John Field and Tim Teitelbaum, Cornell University
Incremental Reduction in the Lambda Calculus
John Hannan and Dale Miller, University of Pennsylvania
From Operational Semantics to Abstract Machines: Preliminary Results
P. Cregut, LIENS-CNRS
An Abstract Machine for Lambda-Terms Normalization
Gopalan Nadathur and Debra Sue Wilson, Duke University
A Representation of Lambda Terms Suitable for Operations on their
Intensions
CONFERENCE INFORMATION
The 1990 ACM Lisp and Functional Programming Conference will be held
in the Acropolis Convention Center, in Nice, France.
Palais des Congres
1, Esplanade Kennedy
06012 NICE
Tel. (33) 93.92.80.80
Nice has a major international airport located less than two miles from
the downtown area, with frequent buses. It is possible to fly direct to Nice
from North America and from most capitals in Europe.
Advance registration for the Conference is highly recommended. If you wish
to receive a latex copy of the conference leaflet, with Registration Form and
Hotel Reservation Form, send a request to kahn@mirsa.inria.fr.
------------------------------
End of Scheme Digest
********************
∂17-Feb-90 2352 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #304
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 17 Feb 90 23:52:31 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA23669; Sun, 18 Feb 90 02:50:51 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Sun, 18 Feb 90 02:49:45 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa23920;
18 Feb 90 2:39 EST
Message-Id: <DIGEST.184.900218.021847.12@MC.LCS.MIT.EDU>
Date: 18 Feb 90 02:18:47 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #304
Scheme Digest #304 18 Feb 90 02:18:47 EST
Today's Topics:
Will macros be defined in r4rs?
----------------------------------------------------------------------
Message-ID: <MAC.90Feb16162254@k9.cad.mcc.com>
Date: 16 Feb 90 22:22:54 GMT
From: Mac Michaels <samsung!cs.utexas.edu!milano!cadillac!mac@think.com>
To: scheme@mc.lcs.mit.edu
Subject: Will macros be defined in r4rs?
I have been comparing Scheme (thanks again to all who helped me find r3rs)
and Common Lisp. On page 37 I discovered that macros were not defined in
Scheme yet. Is it likely that macros will be defined in r4rs?
--
USPS: Mac Michaels, 3500 West Balcones Center Dr., Austin,TX 78759
ARPA: mac@mcc.com
UUCP: {uunet,harvard,gatech,pyramid}!cs.utexas.edu!milano!cadillac!mac
:-)))))))) She had so many chins, she looked like a piece of Lisp code!
------------------------------
End of Scheme Digest
********************
∂18-Feb-90 0722 jinx@zurich.ai.mit.edu Next meeting.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 18 Feb 90 07:22:38 PST
Received: from zurich.ai.mit.edu ([18.43.0.171]) by life.ai.mit.edu (4.0/AI-4.10) id AA25968; Sun, 18 Feb 90 10:19:30 EST
Received: from localhost by zurich.ai.mit.edu; Sun, 18 Feb 90 10:18:15 est
Date: Sun, 18 Feb 90 10:18:15 est
From: jinx@zurich.ai.mit.edu (Guillermo J. Rozas)
Message-Id: <9002181518.AA01393@zurich.ai.mit.edu>
To: rrrs-authors@zurich.ai.mit.edu
Subject: Next meeting.
Reply-To: jinx@zurich.ai.mit.edu
I suggest the next RNRS
meeting be held in White Plains, NY at the SIGPLAN'90 conference in
late June.
I agree that a new meeting is in order. Unfortunately the Lisp
conference is in late June as well, and some of us were planning to
spend some time in Europe around it.
∂19-Feb-90 0255 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #305
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 19 Feb 90 02:55:40 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA05498; Mon, 19 Feb 90 05:53:57 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Mon, 19 Feb 90 05:53:03 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa12888;
19 Feb 90 5:52 EST
Message-Id: <DIGEST.184.900219.054847.18@MC.LCS.MIT.EDU>
Date: 19 Feb 90 05:48:47 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #305
Scheme Digest #305 19 Feb 90 05:48:47 EST
Today's Topics:
Need brief documentation of extend-syntax
----------------------------------------------------------------------
Message-ID: <6451@cps3xx.UUCP>
Date: 14 Feb 90 15:30:27 GMT
From: Douglas K Pierce <samsung!umich!sharkey!cfctech!teemc!ka3ovk!ki4pv!cdin-1!dsinc!netnews.upenn.edu!cps3xx!cpsvax!pierced@think.com>
To: scheme@mc.lcs.mit.edu
Subject: Need brief documentation of extend-syntax
I am interested in developing macros and special forms in PC Scheme that
will simplify the porting of source code between Scheme and Common Lisp.
I have already had some success with this, using the extend-syntax
source file bundled with TI PC Scheme. However, the documentation for
this is practically nil.
I know there is a book, I believe by Dybvig (sp?), that covers this
topic, and hope to purchase it someday. For now, though, I am looking
for some brief documentation on extend-syntax that will take me farther
than I have been able to get on my own. For example, I know there is a
'with' form, but have no idea what it can be used for. Anything at all
would be more than I have now. Thanks much for anything!
Also, if there are others working on this type of project, I would be
interested in corresponding.
And a big *thank you* to whoever started this Scheme newsgroup!
Doug Pierce
AI/KBS Lab
Michigan State
------------------------------
End of Scheme Digest
********************
∂19-Feb-90 0655 halstead@crl.dec.com Re: Next meeting.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 19 Feb 90 06:55:21 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA06892; Mon, 19 Feb 90 09:52:35 EST
Received: from crl.dec.com (crl.dec.com) by zurich.ai.mit.edu; Mon, 19 Feb 90 09:51:44 est
Received: by crl.dec.com; id AA26226; Mon, 19 Feb 90 09:52:00 -0500
Message-Id: <9002191451.AA18373@crlrhh.crl.dec.com>
To: rrrs-authors@zurich.ai.mit.edu
Cc: halstead@crl.dec.com
Subject: Re: Next meeting.
In-Reply-To: Your message of Sun, 18 Feb 90 10:18:15 -0500.
<9002181518.AA01393@zurich.ai.mit.edu>
Date: Mon, 19 Feb 90 09:51:47 EST
From: halstead@crl.dec.com
> I suggest the next RNRS
> meeting be held in White Plains, NY at the SIGPLAN'90 conference in
> late June.
> I agree that a new meeting is in order. Unfortunately the Lisp
> conference is in late June as well, and some of us were planning to
> spend some time in Europe around it.
I too will be in Europe at the time of SIGPLAN '90, so I'd vote for a
different time. -Bert Halstead
∂19-Feb-90 1112 @zurich.ai.mit.edu,@mitvma.mit.edu:CABO@DB0TUI6.BITNET URGENT RESPONSE REQUESTED!!!!!
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 19 Feb 90 11:12:00 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA09701; Mon, 19 Feb 90 14:09:09 EST
Received: from mitvma.mit.edu (mitvma.mit.edu) by zurich.ai.mit.edu; Mon, 19 Feb 90 14:07:05 est
Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 9893; Mon, 19 Feb 90 14:06:13 EST
Received: from DB0TUI6.BITNET (CABO) by MITVMA.MIT.EDU (Mailer R2.05) with
BSMTP id 3014; Mon, 19 Feb 90 14:06:12 EST
Received: by tub.UUCP; Sat, 17 Feb 90 17:58:13 +0100; AA28842
Date: Sat, 17 Feb 90 17:58:13 +0100
From: Carsten Bormann <cabo%TUB.BITNET@mitvma.mit.edu>
Message-Id: <9002171658.AA28842@tub.UUCP>
To: KMP@stony-brook.scrc.symbolics.com, will@cs.uoregon.edu
Cc: rrrs-authors@zurich.ai.mit.edu, scheme-standard@zurich.ai.mit.edu
In-Reply-To: Kent M Pitman's message of Thu, 15 Feb 90 14:34 EST
Subject: URGENT RESPONSE REQUESTED!!!!!
Date: Thu, 15 Feb 90 14:34 EST
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
For the record, here is my position on #f and () ...
I strongly support any resolution to this controversy which leaves all
implementations required to do the same thing. I believe it is a grave
mistake to leave this aspect of the language unspecified.
I already wanted to generate a response that stresses exactly this
point. Kent has saved me some work. Consider me in strong agreement
with him.
I'm spending too much time in standardization activities (in a mildly
unrelated field, that is document representation and processing
standards) to be able to let arguments pass by that only cite
"consensus" instead of technical reasons for making a standard fuzzy.
As a prospective user of Scheme, I'm feeling extremely uncomfortable
with a standards committee that uses its own indecisiveness as an
excuse for forcing extensive hidden costs on its customers.
(This is not a shot against procedural arguments, which may or may not
be valid; I do not understand IEEE procedures sufficiently to know
whether such an issue can be fixed now, can be fixed during resolution
of ballot comments, or requires a new ballot.)
I used to tell students that the main difference between Scheme and
other variants of Lisp was that the Schemers tried to do things right
instead of compatible with what implementers thought to be neat in the
late fifties. If (eq? '() #f) -> fuzz, I'll stop saying that.
Gruesse, Carsten
PS.: I also agree that this is a "small issue". Unfortunately,
often the "small issues" determine whether a standard is useful or not.
The fact that this is a small issue should be instrumental in quickly
reaching consensus (in the sense of everybody saying "I can live with
it, let's move on"), instead of in ignoring the issue.
∂19-Feb-90 1354 @zurich.ai.mit.edu,@mc.lcs.mit.edu:chaynes@iuvax.cs.indiana.edu Comments and poll on () [long message]
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 19 Feb 90 13:53:53 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA01138; Mon, 19 Feb 90 16:49:45 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Mon, 19 Feb 90 16:48:23 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa06479;
19 Feb 90 16:43 EST
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 19 Feb 90 16:44:24 EST
Received: from iuvax.cs.indiana.edu by mintaka.lcs.mit.edu id aa06199;
19 Feb 90 16:38 EST
Received: by iuvax.cs.indiana.edu
Date: Mon, 19 Feb 90 16:38:25 -0500
From: Chris Haynes <chaynes@iuvax.cs.indiana.edu>
To: scheme-standard@wheaties.ai.mit.edu, rrrs-authors@mc.lcs.mit.edu
Subject: Comments and poll on () [long message]
Message-Id: <9002191638.aa06199@mintaka.lcs.mit.edu>
There are (at least) four possible positions in the area of consideration:
A. #F and () may be identical, and () may be false;
B. #F and () may be identical, but () is true if they are distinct;
C. #F and () are distinct, and () may be false;
D. #F and () are distinct, and () is true;
where objects are "identical" if they are EQ?, "false" means
"interpreted as a false value", and "may be X" means "may or may not
be X in a conforming implementation".
Position A was the old status quo, but B has been agreed to by the
RNRS authors. The change from A to B was not made in R3.95RS by an
oversite. Thus B is the real status quo, as reflected in R3.99RS and
P1178/D3 (the most recent IEEE standard draft). It isn't clear to me
whether anyone has argued for C. (It would make condition testing
expensive unless () were false.) The contest seems to be between
positions B and D.
Several statements have been made to the effect that standards are
cast in stone. They are not. They must be revised at least every
five years, and they are supposed to evolve. (Ironically, the current
policy for consensus in RNRS may make its evolution more conservative
than the standard.) Existing practice must be taken into account
before changes are made; however, in the present case this may well
not be a problem. If we go with position B now, no portable code can
rely on #F and () being identical, so it is unlikely that code
compatibility will stand in the way of a change to D when the standard
is revised. If time further tells that few implementations are wedded
to B for reasons such as Common Lisp compatibility or branch test
efficiency (see below), a change to D a few years hence should not be
difficult. On the other hand, it is still true that a change now is
preferable if we have a clear consensus to do so.
So far the Scheme Working Group has maintained policies of not making
binding decisions over the net and of maintaining compatibility with
R4RS. If a position other than B were adopted in a standard draft
submitted to the MSC in March, it would be contrary to the former, and
possibly also the later policy.
However, if the results of the above poll show a clear consensus, I
believe there is justification for making an exception to these
policies for this issue. Though a number of individuals have definite
opinions on this issue, there appears to be substantial, perhaps
universal, feeling that this issue is not worth delaying the
standardization process. (If we miss the March 12th MSC meeting, the
standard will be delayed at least four months.) It is also
questionable whether debate of this issue at a formal meeting would
yield any better agreement, and patience for continued discussion of
this matter in any forum is running thin. However, there are enough
individuals that feel strongly about this issue that if it no change
is made this could result in enough negative ballots for the draft to
be rejected (at least on the first round of balloting). Even if this
does not happen, if there is a substantial consensus on this matter,
the standard should be faithful to that consensus.
If you wish to register an opinion on this issue, respond to the
following poll:
-------------------------------------------------------------------------
I prefer: (choose one of A, B, C, D, or none)
I strongly oppose: (indicate all of A, B, C, and D that apply, or none).
-------------------------------------------------------------------------
Send responses to chaynes@iuvax.cs.indiana.edu by Monday, February
26th. "Strongly oppose" means that if one of the positions you list
were adopted by the standard, you would cast a negative ballot for
that reason. Responses of "none" will be counted as abstentions,
which will dilute the impact of other responses if they are numerous.
In using the results of this poll, the standard editors first concern
will be to avoid a position to which there is sizable opposition.
Second, if there is substantial preference for a position to which
very few are strongly opposed, that position will be adopted. If
there is no strong opposition to position B, and no substantial
consensus favoring another position, then the status quo (B) will be
maintained. (Put simply: if the poll is anywhere near close, the nod
goes to B. The poll is for the editors' information; it is not a
formal vote.)
My summary of B vs D:
Position D is attractive to many who feel it simplifies the
language semantics. If we stay with position B, it will not be
possible to define a useful subset of Scheme in a reasonably
precise way (as in a book I'm working on) without this ugly issue
getting in the way. This confuses readers and makes Scheme (and
us) look bad. Also, as has been repeatedly noted, experience
demonstrates that punning #F and () results in subtle bugs.
In the past, a major reason for favoring position B over D was that
B allows Common Lisp to be built on top of Scheme without having to
redefine a great many primitives. I think this still carries some
weight, as does the consideration that some hardware can test one
value (e.g. 0) more efficiently than others, so it is nice to be
able to use this value for both #F and ().
My response to the poll:
I prefer: D
I strongly oppose: none
∂19-Feb-90 1411 @zurich.ai.mit.edu,@MC.lcs.mit.edu,@zermatt.lcs.mit.edu:ziggy@hx.lcs.mit.edu RE: (#F v. ()) v. Standardization
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 19 Feb 90 14:11:23 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA01398; Mon, 19 Feb 90 17:07:43 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Mon, 19 Feb 90 17:06:01 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa07342;
19 Feb 90 17:03 EST
Received: from ZERMATT.LCS.MIT.EDU (CHAOS 17316) by MC.LCS.MIT.EDU; 19 Feb 90 17:03:56 EST
Received: from HX.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via INTERNET with SMTP id 12326; 19 Feb 90 17:03:47 EST
Received: by hx.LCS.MIT.EDU (5.51/4.7); Mon, 19 Feb 90 17:03:37 EST
Date: Mon, 19 Feb 90 17:03:37 EST
From: "Michael R. Blair" <ziggy@hx.lcs.mit.edu>
Message-Id: <9002192203.AA10322@hx.LCS.MIT.EDU>
To: rrrs-authors@zermatt.lcs.mit.edu
Subject: RE: (#F v. ()) v. Standardization
>>From: Carsten Bormann <cabo%TUB.BITNET@mitvma.mit.edu>
>>
>>As a prospective user of Scheme, I'm feeling extremely uncomfortable
>>with a standards committee that uses its own indecisiveness as an
>>excuse for forcing extensive hidden costs on its customers.
Perhaps this is an indication that it is inadvisable to attempt to
over-standardize a language...that is, while there are still
experimentors actively experimenting with the language. I see two
ways to resolve this. Stop attempting to standardize experiment-
relevant language features, or stop doing experiments using the
language. As a hacker rather than a bureaucrat, my sentiments lay
with the former option.
Why can't the standards committee just leave the issue fuzzy while the
R↑NRS mailing list settles on a well-reasoned solution? Certainly,
such a trivial matter cannot keep reasonable people awake at night?
And certainly there are other things on your agenda besides this
``small'' issue?
~Ziggy
P.S. There, is that equally as inflamatory as the comment which
inspired a reply? Or should I add something like ``I used to
say that prospective Scheme users wanted a language that does the
right thing, but if they would rather we standardize haphazardly,
then I will have to stop saying that.''
∂19-Feb-90 1419 jeff%aiai.edinburgh.ac.uk@nsfnet-relay.ac.uk Re: URGENT RESPONSE REQUESTED!!!!!
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 19 Feb 90 14:19:14 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA01476; Mon, 19 Feb 90 17:14:40 EST
Received: from NSFnet-Relay.AC.UK (nsfnet-relay.ac.uk) by zurich.ai.mit.edu; Mon, 19 Feb 90 17:13:27 est
Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK
via Janet with NIFTP id aa27817; 19 Feb 90 21:05 GMT
Date: Mon, 19 Feb 90 20:50:23 GMT
Message-Id: <18673.9002192050@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@nsfnet-relay.ac.uk>
Subject: Re: URGENT RESPONSE REQUESTED!!!!!
To: Carsten Bormann <@mitvma.mit.edu:cabo@tub.bitnet>,
KMP@stony-brook.scrc.symbolics.com,
will%cs.uoregon.edu@nsfnet-relay.ac.uk
In-Reply-To: Carsten Bormann's message of Sat, 17 Feb 90 17:58:13 +0100
Cc: rrrs-authors@zurich.ai.mit.edu, scheme-standard@zurich.ai.mit.edu
> I'm spending too much time in standardization activities (in a mildly
> unrelated field, that is document representation and processing
> standards) to be able to let arguments pass by that only cite
> "consensus" instead of technical reasons for making a standard fuzzy.
> As a prospective user of Scheme, I'm feeling extremely uncomfortable
> with a standards committee that uses its own indecisiveness as an
> excuse for forcing extensive hidden costs on its customers.
> I used to tell students that the main difference between Scheme and
> other variants of Lisp was that the Schemers tried to do things right
> instead of compatible with what implementers thought to be neat in the
> late fifties. If (eq? '() #f) -> fuzz, I'll stop saying that.
There are a number of things in Scheme that are "fuzzy" (ie, unspecified).
The (eq? '() #f) question is one case where many people think the result
should be specified, but technical reasons have been cited on both sides.
You think a particular solution is right, but other people don't. The
procedural question is: how do we resolve disagreements of this sort.
∂19-Feb-90 1521 @zurich.ai.mit.edu,@mc.lcs.mit.edu,@relay.cs.net,@tektronix.tek.com:kend@mrloog.wr.tek.com Re: Comments and poll on () [long message]
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 19 Feb 90 15:21:10 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA02249; Mon, 19 Feb 90 18:11:54 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Mon, 19 Feb 90 18:11:06 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa09930;
19 Feb 90 18:07 EST
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 19 Feb 90 18:08:01 EST
Received: from relay.cs.net by mintaka.lcs.mit.edu id aa09848;
19 Feb 90 18:05 EST
Received: from tektronix.tek.com by RELAY.CS.NET id aa17633; 19 Feb 90 17:05 EST
Received: by tektronix.TEK.COM (5.51/7.1)
id AA28899; Mon, 19 Feb 90 15:09:14 PST
Received: by wrgate.wr.tek.com (5.51/7.1)
id AA26798; Mon, 19 Feb 90 15:05:26 PST
Received: by mrloog.WR.TEK.COM (1.2/7.1)
id AA18830; Mon, 19 Feb 90 15:05:40 pst
Message-Id: <9002192305.AA18830@mrloog.WR.TEK.COM>
To: Chris Haynes <chaynes@iuvax.cs.indiana.edu>
Cc: scheme-standard@wheaties.ai.mit.edu, rrrs-authors@mc.lcs.mit.edu,
kend@mrloog.wr
Subject: Re: Comments and poll on () [long message]
In-Reply-To: Your message of Mon, 19 Feb 90 16:38:25 -0500.
<9002191638.aa06199@mintaka.lcs.mit.edu>
Date: 19 Feb 90 15:05:34 PST (Mon)
From: kend@mrloog.wr.tek.com
I prefer D, but if D is not the case, I prefer to mandate the identity of
#F and '().
-------------------------------------------------------------------------
I prefer: D
I strongly oppose: C
-------------------------------------------------------------------------
-Ken Dickey kend@mrloog.WR.TEK.COM
∂19-Feb-90 2143 rauen@brokaw.lcs.mit.edu Module proposal [long]
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 19 Feb 90 21:43:11 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA07231; Tue, 20 Feb 90 00:38:15 EST
Received: from brokaw.LCS.MIT.EDU (brokaw.lcs.mit.edu) by zurich.ai.mit.edu; Tue, 20 Feb 90 00:37:18 est
Received: by brokaw.LCS.MIT.EDU
id AA04375; Tue, 20 Feb 90 00:37:42 EST
Date: Tue, 20 Feb 90 00:37:42 EST
From: rauen@brokaw.lcs.mit.edu (James R. Rauen)
Message-Id: <9002200537.AA04375@brokaw.LCS.MIT.EDU>
To: rrrs-authors@zurich.ai.mit.edu
Subject: Module proposal [long]
Slipping away from the #f .EQ. '() brouhaha momentarily, here is a
module proposal for R5RS. The proposal is based on a design by Pavel
Curtis and myself, currently being implemented at Xerox PARC.
Two prefatory comments:
1. Modules are not first class. In essence, they are statically
checkable binding forms; in this respect they are similar to
definitions.
2. Sections 4 and 5 of the proposal, which deal with syntax, are a bit
dated given the "painting" algorithm that supersedes syntactic
closures. However, I don't see any fundamental problems with updating
this.
Jim Rauen
545 Technology Square, Room NE43-440
Cambridge, MA 02139
(617) 253-0884
rauen@brokaw.lcs.mit.edu
======================================================================
Module System Proposal
----------------------
0. Design Goals
Our principal design goal is to support very large scale programming
in Scheme. This goal affects several fundamental design decisions,
such as not having first-class modules. Other major goals are:
* The semantics must be static; they should not require any notion
of state or mutation. However, the semantics must accomodate such
tools as separate compilation, read-eval-print loops, and dynamic
loading.
* Static checks (for example, checking unbound variables,
unimplemented or multiply implemented interfaces, and incorrect
inter-module references) must be possible.
* Syntactic extension must be accomodated and well-specified,
especially given separate compilation.
1. Overview
The foundation of the module system is the Scheme language as (will
be) defined in the Revised↑4 Report. R4RS defines a Scheme program as
a sequence of definitions and expressions.
The module system adds several new kinds of program components:
interfaces, modules, syntax definitions, and meta-modules.
2. Interfaces
An interface is a collection of specifications of variables. The
specification of a variable includes an identifier that names the
variable, and (optionally) other information about the variable, such
as its type. Each variable should be accompanied by a comment that
informally describes the variable.
Example:
(INTERFACE hash-table ; Mutable hash tables.
(VALUE create) ; (create) returns a new, empty table
(VALUE insert!) ; (insert! tab key val) associates key
; with val in tab.
(VALUE lookup) ; (lookup tab key) returns associated
; value for key in tab, or #f if
) ; there is none
3. Modules
A module is an isolated scope that contains a complete program. The
program inside the module can only communicate outside the module by
explicitly exporting and importing variables.
[More correctly, modules share value bindings. However, since there
is a one-to-one correspondence between the shared variables and the
shared value bindings, I will generally use the phrase "shared
variable".]
3.1 Exports
A module provides a variable to other modules by exporting the
variable. The variable must have a specification in some interface
that is lexically visible to the exporting module. The module
includes an EXPORTS clause that lists the names of the
interface and the exported variable.
The program inside the exporting module must either contain
a definition of the variable or contain a module that itself exports
the variable.
For brevity's sake, the export clauses (EXPORTS e1), ..., (EXPORTS en)
may be combined into (EXPORTS e1 ... en). If a module exports all the
variables specified in an interface, without any renaming, then the
module may simply (EXPORTS interface-name). Also, if a module exports
more than one frob from an interface, there is the syntax (EXPORTS
(interface-name frob1 frob2 ...)).
Example:
(MODULE ((EXPORTS (hash-table create insert! lookup)))
(DEFINE create (LAMBDA () ...))
(DEFINE insert! (LAMBDA (tab key val) ...))
(DEFINE lookup (LAMBDA (tab key) ...)))
3.2 Imports
A module gains access to variables in other modules by importing the
variables. An imported variable must have a specification in an
interface, and there must be a module at the appropriate scoping level
(3.6, below) that exports the variable. The importing module
contains an import clause of the form (IMPORTS (interface-name
identifier)), where the interface-name and identifier indicate which
variable is desired.
Like exports, the import clauses (IMPORTS i1), ..., (IMPORTS in) may
be combined into (IMPORTS i1 ... in), and if a module imports
everything specified in an interface, then the module may simply
(IMPORTS interface-name). Also, if a module imports more than one
frob from an interface, there is the syntax (IMPORTS (i-name frob1
frob2 ...)).
The program inside a module uses an ACCESS form to obtain the value of
an imported variable. The access form may either be written (ACCESS
ifcname varname) or ifcname#varname. The reader transforms the latter
syntax into the former.
An imported variable may not be assigned to. Side-effects are always
restricted to the module where the variable is defined. However, a
module can certainly export procedures that modify its variables.
Example:
(MODULE ((IMPORTS hash-table))
(DEFINE ht (hash-table#create))
(hash-table#insert! ht 'foo 3)
(hash-table#lookup ht 'foo) ; => 3
)
3.3 Opening imported variables
To avoid the nuisance of having to qualify imported variable names
with their interfaces, a module can "open" any binding it imports. By
opening the binding, the module introduces a new name, local to the
module, by which the imported binding can be referred to.
The new name defaults to the imported variable name. To obtain this
behavior, the module contains an open clause of the form
(OPEN (interface-name identifier)). To use a different name, the
module should contain a clause of the form (OPEN (i-name
(id-in-module id-in-interface))). Open clauses may be abbreviated in
the same way as import and export clauses.
Example:
(MODULE ((IMPORTS hash-table) (OPEN hash-table))
(DEFINE ht (create))
(insert! ht 'foo 3)
(lookup ht 'foo) ; => 3
)
3.4 Tree structure of programs
Because programs contain modules, and each module itself contains a
program, programs have a tree structure. At the root of the tree is
the outermost (``closed'') program. Its children are the closed
program's components, which include definitions, expressions,
interfaces, and modules. Each module has a child of its own, the
program that the module contains.
3.5 Scope of interfaces
An interface defined in a program P is visible to all the programs
that are descendants of P, unless shadowed by another interface
definition of the same name.
3.6 Scope of shared variables
The scope of a shared variable is the set of programs that have access
to the binding that implements the variable. Three rules determine
the scope of a shared variable:
1. A shared variable is available in the program where it is defined.
(This is the only program that can mutate the variable.)
2. A shared variable is available in any program containing a module
that exports the variable.
3. A shared variable is available in any program inside a module that
imports the variable. The importing module must either occur within
the same program as the exporting module, or nested inside another
module that imports the binding.
These rules allow there to be more than one shared variable
corresponding to a particular value specification in an interface.
For example, consider the following program. The labels on the left
identify each program (P#) and each module (M#) for identification
purposes and to depict the tree structure.
[P0] (INTERFACE foo (VALUE bar))
[P0]
[P0][M1] (MODULE ((EXPORTS foo))
[P0][M1][P1][M2] (MODULE ((EXPORTS foo))
[P0][M1][P1][M2][P2] (DEFINE bar 1)))
[P0]
[P0][M3] (MODULE ((IMPORTS foo))
[P0][M3][P3] foo#bar)
[P0]
[P0][M4] (MODULE ()
[P0][M4][P4][M5] (MODULE ((EXPORTS foo))
[P0][M4][P4][M5][P5] (DEFINE bar 2))
[P0][M4][P4][M6] (MODULE ((IMPORTS foo))
[P0][M4][P4][M6][P6] foo#bar))
The above program contains two shared variables corresponding to the
specification of bar in interface foo. The first variable, defined in
program P2, is available to programs P0, P1, P2, and P3. The second
variable, defined in program P5, is available to programs P4, P5, and
P6.
4. Syntactic extension
Syntactic extensions (macros) are how new kinds of expressions are
defined. The semantics of a syntactic extension are given by a
procedure that transforms instances of the new syntax into other
forms.
4.1 Syntax definitions
The syntax definition (DEFINE-SYNTAX identifier meta-expression)
introduces a syntactic extension whose scope is the program where the
syntax definition occurs.
The meta-expression is interpreted in the initial environment and
store. It should evaluate to a transformation procedure. The
meta-expression may close over variables and perhaps mutate these
variables. The semantics of syntax invocation takes this into
account.
4.2 Syntax invocation
A syntactic extension is invoked by a list form whose first element is
an identifier that has a syntax definition.
When syntax is invoked, something equivalent to the following happens.
The meta-expression for the syntax is evaluated in an initial
environment and store. The resulting procedure is applied an
arbitrary number of times to arbitrary forms, registering any
side-effects in the store. Finally, the transformation procedure is
applied to the list form; the result is used in place of the original
list form.
4.3 Shared syntax
Modules can share syntactic extensions. Shared syntax obeys the same
scoping rules that shared variables do. Interfaces may contain syntax
specifications analogous to variable specifications. Modules may
import, export, and open syntactic extensions in the same way as they
do variables.
4.4 Syntactic environments
A syntactic environment associates identifiers with their static
meanings. An identifier may be mapped to any of:
* An interface
* A syntactic extension
* A primitive syntax description
* A variable
Syntactic environments can be used to control the scoping of names by
transformation procedures, as described by Bawden and Rees ("Syntactic
Closures", Lisp and Functional Programming 1988).
5. Meta-modules
A meta-module is an isolated scope containing a program called a
meta-program. The meta-module can export some of the meta-program's
variables to be used as syntax transformation procedures.
Meta-modules are used to implement syntactic extensions that cannot be
handled easily with DEFINE-SYNTAX. Two situations where this is
likely are (1) when a syntactic extension is so complicated that it is
best implemented with an entire program, and (2) when several
syntactic extensions wish to share auxiliary procedures.
5.1 Exports
The exports of a meta-module must have syntax specifications. Within
the meta-program, however, they are treated as regular variables.
Each exported syntactic extension must either be implemented by a
top-level variable definition in the meta-program, or be exported by
some module in the meta-program.
Example:
(INTERFACE stackish-ops (SYNTAX push))
(META-MODULE ((EXPORTS (stackish-ops push)))
(DEFINE push (LAMBDA (form env) ...)))
5.2 Imports and Opens
The imports and opens of a meta-module establish a syntactic
environment. This syntactic environment is an extension of the
initial syntactic environment, with additional entries for the items
that the meta-module imports and opens. This syntactic environment is
considered to be the "environment of definition" of syntax exported by
the meta-module.
5.3 Invocation of meta-module syntax
When syntax defined by a meta-module is invoked, something equivalent
to the following happens. The meta-program is evaluated in the
initial environment and store. The resulting transformation
procedures are applied, in arbitrary order, an arbitrary number of
times to arbitrary forms. All side-effects from the evaluation and
applications are registered in the store. Finally, the appropriate
transformation procedure is applied to the form invoking the syntax,
and the resulting form is used in place of the original.
Invocation of syntax defined by a meta-module follows essentially the
same rules as those given in 4.2, above. However, in the stage of
arbitrary applications, any transformation procedure in the
meta-module may be applied.
6. Initial environments
Every program implicitly imports and opens the SCHEME interface. The
SCHEME interface specifies the primitive procedures and syntax defined
in the Scheme report. It also specifies the module system syntax
itself (ACCESS, INTERFACE, MODULE, etc.) and several other useful
procedures (MAKE-SYNTACTIC-CLOSURE, etc.). A module may forego this
default for its body program by including WITHOUT-OPENING-SCHEME in
its externals.
7. Grammar
p: Program ::= (d | e | i | m | mm)*
d: Definition ::= (DEFINE id e)
| (DEFINE-SYNTAX id me)
e: Expression ::= usual Scheme expressions
| (ACCESS in id)
| (id q*) ; syntactic extension
| ((ACCESS in id) q*) ; syntactic extension
i: Interface ::= (INTERFACE in s*)
s: Spec ::= (VALUE id at*)
| (SYNTAX id at*)
at: Attribute ; not specified
m: Module ::= (MODULE (x*) p)
x: External ::= (EXPORTS {in | (in {id | (id id)}*)}*)
| (IMPORTS {in | (in id*)}*)
| (OPEN {in | (in {id | (id id)}*)}*)
| WITHOUT-OPENING-SCHEME
mm: MetaModule ::= (META-MODULE (x*) mp)
me: MetaExpr ::= e
mp: MetaProgram ::= p
in: IfcName ::= id
id: Identifier
q: Datum
The grammar does not reflect the following:
* syntactic sugar for DEFINE forms
* the shorthand in#id for (ACCESS in id)
∂20-Feb-90 0021 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #306
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 20 Feb 90 00:21:17 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA08977; Tue, 20 Feb 90 03:19:35 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Tue, 20 Feb 90 03:18:16 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa28268;
20 Feb 90 2:57 EST
Message-Id: <DIGEST.184.900220.022424.3@MC.LCS.MIT.EDU>
Date: 20 Feb 90 02:24:24 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #306
Scheme Digest #306 20 Feb 90 02:24:24 EST
Today's Topics:
Public domain SCHEME.
Boxes -- what exactly are these?
----------------------------------------------------------------------
Message-ID: <233@rangkom.MY>
Date: 19 Feb 90 03:28:24 GMT
From: "Mohd Hanafiah b. Abdullah" <mimos!rangkom!napi@uunet.uu.net>
To: scheme@mc.lcs.mit.edu
Subject: Public domain SCHEME.
Could anyone please inform me of how to get source code for the SCHEME
programming language.
I prefer to have the source, but binaries for the VAX, Convex, Apollo, or
Sun III is fine.
Thank you very much.
Mohd Hanafiah Abdullah.
------------------------------
Message-ID: <1990Feb20.005537.25572@sun.soe.clarkson.edu>
Date: 20 Feb 90 00:55:37 GMT
From: Jason Coughlin <image.soe.clarkson.edu!jk0@uunet.uu.net>
To: scheme@mc.lcs.mit.edu
Subject: Boxes -- what exactly are these?
I saw an implementation of boxes that looks like this:
(define box (lambda (x) (cons x #f)))
(define unbox (lambda (x) (car x)))
(define set-box! (lambda (x v) (set-car! x v)))
Is the point akin to a pointer in C? ie, so you could have args that
"changed" (call by variable)?
Is this an OK defn of boxes?
--
Jason Coughlin ( jk0@sun.soe.clarkson.edu , jk0@clutx )
"Every jumbled pile of person has a thinking part that wonders what the
part that isn't thinking isn't thinking of." - They Might Be Giants
------------------------------
End of Scheme Digest
********************
∂20-Feb-90 0912 @zurich.ai.mit.edu,@mc.lcs.mit.edu:mkatz@garlic.stanford.edu Comments and poll on () [long message]
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 20 Feb 90 09:12:35 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA14579; Tue, 20 Feb 90 12:08:58 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Tue, 20 Feb 90 12:07:33 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa16575;
20 Feb 90 11:48 EST
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 20 Feb 90 11:49:36 EST
Received: from garlic.Stanford.EDU by mintaka.lcs.mit.edu id aa16418;
20 Feb 90 11:45 EST
Received: by garlic.Stanford.EDU (5.57/Ultrix3.0-C)
id AA09969; Tue, 20 Feb 90 08:40:47 PST
Date: Tue, 20 Feb 90 08:40:47 PST
From: Morris Katz <mkatz@garlic.stanford.edu>
Message-Id: <9002201640.AA09969@garlic.Stanford.EDU>
To: chaynes@iuvax.cs.indiana.edu
Cc: scheme-standard@wheaties.ai.mit.edu, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Chris Haynes's message of Mon, 19 Feb 90 16:38:25 -0500 <9002192139.AA00942@life.ai.mit.edu>
Subject: Comments and poll on () [long message]
Date: Mon, 19 Feb 90 16:38:25 -0500
From: Chris Haynes <chaynes@iuvax.cs.indiana.edu>
-------------------------------------------------------------------------
I prefer: (choose one of A, B, C, D, or none)
I strongly oppose: (indicate all of A, B, C, and D that apply, or none).
-------------------------------------------------------------------------
I prefer D and strongly oppose A and C.
-------------------------------------------------------------------------------
Morry Katz
katz@cs.stanford.edu
-------------------------------------------------------------------------------
∂20-Feb-90 1116 @zurich.ai.mit.edu,@mc.lcs.mit.edu,@ti.com:Gateley@tilde.csc.ti.com Retracted vote.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 20 Feb 90 11:16:00 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA17051; Tue, 20 Feb 90 14:11:33 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Tue, 20 Feb 90 14:09:57 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22553;
20 Feb 90 14:06 EST
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 20 Feb 90 14:06:54 EST
Received: from TI.COM by mintaka.lcs.mit.edu id aa22404; 20 Feb 90 14:01 EST
Received: by ti.com id AA23160; Tue, 20 Feb 90 13:00:45 -0600
Received: from Casablanca by tilde id AA08356; Tue, 20 Feb 90 12:49:27 CST
Message-Id: <2844528546-5163313@Casablanca>
Sender: GATELEY@casablanca.csc.ti.com
Date: Tue, 20 Feb 90 12:49:06 CST
From: John Gateley <Gateley@tilde.csc.ti.com>
To: chaynes@iuvax.cs.indiana.edu, scheme-standard@wheaties.ai.mit.edu,
rrrs-authors@mc.lcs.mit.edu
Subject: Retracted vote.
My apologies to everyone: I misread the votes.
I support D, and strongly oppose none.
I support have #t and '() be eq? even more, though, but will not fight
the entire community over it.
John
gateley@m2.csc.ti.com
∂20-Feb-90 1347 @zurich.ai.mit.edu,@mc.lcs.mit.edu:KMP@stony-brook.scrc.symbolics.com Comments and poll on () [long message]
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 20 Feb 90 13:47:02 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA20694; Tue, 20 Feb 90 16:41:29 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Tue, 20 Feb 90 16:39:44 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa29467;
20 Feb 90 16:36 EST
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 20 Feb 90 16:37:26 EST
Received: from STONY-BROOK.SCRC.SYMBOLICS.COM by mintaka.lcs.mit.edu id aa23764;
20 Feb 90 14:32 EST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 746792; 20 Feb 90 14:32:33 EST
Date: Tue, 20 Feb 90 14:32 EST
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Subject: Comments and poll on () [long message]
To: chaynes@iuvax.cs.indiana.edu
Cc: scheme-standard@wheaties.ai.mit.edu, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: <9002191638.aa06199@mintaka.lcs.mit.edu>
Message-Id: <19900220193222.1.KMP@BOBOLINK.SCRC.Symbolics.COM>
Summary (new items called E and F are defined in `Detail' section below):
I strongly prefer: D, F.
I strongly oppose: A, B, C, E.
Rationale:
I strongly oppose A, B, and C because I do not think that it is acceptable to
have "may be" involved in this definition. Note that C seems especially idiotic
since it introduces an incompatible change and yet even having paid this price
still does not go to enough work to make sure that all implementations agree.
In fact, I could live with E because it is at least well-defined, but it
seems to defeat the purpose of separating #F and (). If the only purpose
of doing this was just a stepping stone to position D, then I'd rather
just get to D all in one shot.
Detail:
Date: Mon, 19 Feb 90 16:38:25 -0500
From: Chris Haynes <chaynes@iuvax.cs.indiana.edu>
There are (at least) four possible positions in the area of consideration:
A. #F and () may be identical, and () may be false;
B. #F and () may be identical, but () is true if they are distinct;
↑
Just to clarify, pragmatics dictates that "iff" is implied here.
C. #F and () are distinct, and () may be false;
D. #F and () are distinct, and () is true;
I would add:
E. #F and () are distinct, and () must be false;
F. #F and () must be identical (and must be false);
There are some pragmatically nonsensical ones which I've omitted.
The following table captures the above:
identical? () false?
A. maybe maybe
B. maybe iff not identical
C. no maybe
D. no no
E. no yes
F. yes yes
Since I've got you on the line, let me make one more appeal to
portability issues:
I converted Macsyma (a 100,000 line piece of code) from Maclisp/Zetalisp
to Common Lisp. Probably -the- hardest thing to convert was QUOTIENT.
The reason was that (QUOTIENT 3 4) had a straightforward rewrite and
(QUOTIENT 3.0 4.0) had a straightforward rewrite, but mathematically the
two operators were not related. The problem is that (QUOTIENT X Y) has
no efficient rewrite because you may not know the types of X and Y and
cannot efficiently select a rewrite. This means that compatibility code
ran yuckily because the translation had to do something to the effect of:
(IF (OR (TYPEP X 'FLOAT) (TYPEP Y 'FLOAT)) (/ X Y) (TRUNCATE X Y))
That is, the definition of QUOTIENT was not usefully well-defined. It only
-looked- well-defined because it was not ambiguous.
In psychology class, we studied something called "natural concept". The
claim went something like that a `natural concept' is a categorization
that can be defined without the use of "or". That is, if you defined
that a `bleen' was something that was `blue up until tuesday or that was
green afterward.' Another example was that something was `smig' if it
was `big and blue or small and green.' The professor used to make the
observation that this was a kind of categorization that people do not
normally do. But I never saw the relevance. So what? So they don't do
it. What good is that to me. Well, the good seems to me to be here and
now. So that I can recognize that what you are doing is provably not
going to map onto the natural conceptual structure of normal people.
There is only one category of people I can think of who regularly employ
these so-called `unnatural concepts': politicians. That's because they
don't ever really decide things. They just make `plausible looking'
statements that superficially appear to bring people together when
really they have only papered over deep-rooted discontent with wording
that gives the momentary illusion of progress. So what I see right now
is a big red flag of an organization that is growing up to be just as
uglily political as the `commoners' it seeks to be unlike.
I am convinced that there is no universal right to be had here--so I
don't think the details of which road you take is going to matter. They
all lead different places but each of the places is respectable and
people will get work done. But driving in your stake at a fork in the
road and refusing to go further will clearly cost people real amounts of
time and effort--day in and day out, people will pay for every
individual's unwillingness to compromise and produce a clear answer to
this problem. The solution to the porting problem I described for
QUOTIENT will be the kind of thing that will haunt programs for years to
come.
And one last parting point: 5 years is a long time. Even if you don't
think that things are "cast in concrete" by this standard because it
must be reviewed every five years, consider that five years may be
longer than the funding cycle of many projects that have to work in
whatever standard is produced. Perhaps worse, 5 years may be time
enough to evolve still more code so that the decision to change things
is even more costly at that point--and -then- wait until you see the
politics that come when you try to change it. If you think something is
a problem now, then now is the time to fix it.
∂20-Feb-90 1352 @zurich.ai.mit.edu,@mc.lcs.mit.edu,@chaos.cs.brandeis.edu:jmiller@macadamia Comments and poll on ()
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 20 Feb 90 13:52:27 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA20842; Tue, 20 Feb 90 16:47:01 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Tue, 20 Feb 90 16:45:47 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa29484;
20 Feb 90 16:37 EST
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 20 Feb 90 16:37:59 EST
Received: from chaos.cs.brandeis.edu by mintaka.lcs.mit.edu id aa24829;
20 Feb 90 14:55 EST
Received: from macadamia.cs.brandeis.edu by chaos Tue, 20 Feb 90 14:55:35 -0500
Received: by macadamia (5.57/UofC3.0)
id AA03794; Tue, 20 Feb 90 14:53:07 EST
Date: Tue, 20 Feb 90 14:53:07 EST
From: Jim Miller <jmiller@macadamia.ai.mit.edu>
Message-Id: <9002201953.AA03794@macadamia>
To: chaynes@iuvax.cs.indiana.edu, scheme-standard@wheaties.ai.mit.edu,
rrrs-authors@mc.lcs.mit.edu
Subject: Comments and poll on ()
Reply-To: JMiller@chaos.cs.brandeis.edu
STOP IT. The point of this ballot is *NOT* to get more rationale,
argument, debate, and comment. Just send your votes quietly to Chris
Haynes and let us all get back to more important work.
--Jim
∂20-Feb-90 1353 @zurich.ai.mit.edu,@mc.lcs.mit.edu:Marshall.wbst@xerox.com Re: Comments and poll on () [long message]
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 20 Feb 90 13:53:14 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA20881; Tue, 20 Feb 90 16:48:16 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Tue, 20 Feb 90 16:47:15 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa29730;
20 Feb 90 16:41 EST
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 20 Feb 90 16:39:22 EST
Received: from Xerox.COM by mintaka.lcs.mit.edu id aa26853; 20 Feb 90 15:38 EST
Received: from Aurora.ms by ArpaGateway.ms ; 20 FEB 90 12:25:54 PST
Date: 20 Feb 90 15:23 EST
From: Marshall.wbst@xerox.com
Subject: Re: Comments and poll on () [long message]
In-Reply-To: Chris Haynes <chaynes@iuvax.cs.indiana.edu>'s message of Mon,
19 Feb 90 16:38:25 -0500
To: Chris Haynes <chaynes@iuvax.cs.indiana.edu>
Cc: scheme-standard@wheaties.ai.mit.edu, rrrs-authors@mc.lcs.mit.edu
Message-Id: <900220-122554-1389@Xerox>
A. #F and () may be identical, and () may be false;
B. #F and () may be identical, but () is true if they are distinct;
C. #F and () are distinct, and () may be false;
D. #F and () are distinct, and () is true;
I prefer: D.
I strongly oppose: A, B, C.
I would accept #F and () are distinct, and () must be false.
Basically I oppose a standard that does not precisely specify the results
of an operation. I would also accept "it is an error ... to test the truth
of () {and implementations are encouraged to detect this error}". I would
also accept requiring #f and () to be the same object.
--Sidney Marshall
∂21-Feb-90 0811 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #307
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Feb 90 08:11:48 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA00415; Wed, 21 Feb 90 03:28:56 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Wed, 21 Feb 90 03:27:48 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa21231;
21 Feb 90 3:06 EST
Message-Id: <DIGEST.184.900221.020926.9@MC.LCS.MIT.EDU>
Date: 21 Feb 90 02:09:26 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #307
Scheme Digest #307 21 Feb 90 02:09:26 EST
Today's Topics:
Scheme as 1st language (3 messages)
problems/risks due to programming language, stories requested
comp.lang.functional
----------------------------------------------------------------------
Message-ID: <9002200317.aa29302@mintaka.lcs.mit.edu>
Date: Mon, 19 Feb 90 09:40 GMT
From: STCS8004%IRUCCVAX.UCC.IE@mitvma.mit.edu
To: SCHEME@MC.lcs.mit.edu
Subject: Scheme as 1st language
I am soliciting the community's views regarding the choice of Scheme as
the first programming language to be taught to students majoring in
Computer Science.
The Department of Computer Science at University College Cork, Ireland
is undertaking a major restructuring of its Honours Degree program in
the Faculties of Arts and of Science and the question has arisen whether
or not the time given to Pascal would be better utilized in some other
way, such as algorithm design and analysis, for instance. We presently
teach the full standard Pascal to our first-year students in a course of
52 lectures over 26 weeks, plus the usual tutorial/practical sessions.
There is also a 1 hour per week course of lectures on non-Pascal intro-
ductory Computer Science topics.
I would be interested to receive views on the what the first programming
language should be, and to learn of the experiences---good or bad---of
those who have switched away from Pascal to something else.
We presently use Scheme extensively in our 'Data Structures' and
'Compiler Theory and Practice' courses with great success, the students
being largely self-taught Scheme through Friedman and Felleisen's 'The
Little LISPer'. It is seeing how much quicker students can understand,
analyze, and undertake proofs of correctness of the relevant algorithms
expressed in Scheme that prompts the consideration of using some form of
small non-trivial functional programming language at an earlier stage in
their education.
I consider that the fundamentals of algorithm design and programming
style should be taught with the minimum of syntactic baggage, and only
then should a study of alternative programming languages and styles be
undertaken---but what are your views, please?
G. Oulsnam.
------------------------------
Message-ID: <9002200317.aa29279@mintaka.lcs.mit.edu>
Date: Thu, 15 Feb 90 14:52 GMT
From: STCS8004%IRUCCVAX.UCC.IE@mitvma.mit.edu
To: SCHEME@MC.lcs.mit.edu
Subject: Scheme as 1st language
I am soliciting the community's views regarding the choice of Scheme as
the first programming language to be taught to students majoring in
Computer Science.
The Department of Computer Science at University College Cork, Ireland
is undertaking a major restructuring of its Honours Degree program in
the Faculties of Arts and of Science and the question has arisen whether
or not the time given to Pascal would be better utilized in some other
way, such as algorithm design and analysis, for instance. We presently
teach the full standard Pascal to our first-year students in a course of
52 lectures over 26 weeks, plus the usual tutorial/practical sessions.
There is also a 1 hour per week course of lectures on non-Pascal intro-
ductory Computer Science topics.
I would be interested to receive views on the what the first programming
language should be, and to learn of the experiences---good or bad---of
those who have switched away from Pascal to something else.
We presently use Scheme extensively in our 'Data Structures' and
'Compiler Theory and Practice' courses with great success, the students
being largely self-taught Scheme through Friedman and Felleisen's 'The
Little LISPer'. It is seeing how much quicker students can understand,
analyze, and undertake proofs of correctness of the relevant algorithms
expressed in Scheme that prompts the consideration of using some form of
small non-trivial functional programming language at an earlier stage in
their education.
I consider that the fundamentals of algorithm design and programming
style should be taught with the minimum of syntactic baggage, and only
then should a study of alternative programming languages and styles be
undertaken---but what are your views, please?
G. Oulsnam.
------------------------------
Message-ID: <6835@ubc-cs.UUCP>
Date: 20 Feb 90 19:20:31 GMT
From: Vincent Manis <snorkelwacker!usc!zaphod.mps.ohio-state.edu!van-bc!ubc-cs!manis@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: Scheme as 1st language
The classical way to introduce computer science via Scheme is Abelson
and Sussman's `Structure and Interpretation of Computer Programs',
published by MIT Press/McGraw-Hill. Paradoxically, this book is not
about Scheme, and hardly mentions it. Instead, the book concentrates
upon fundamental principles of computer science, paradigms of program
design, and the structures of various evaluators, including interpreters
and compilers for Scheme. The goal isn't so much to have the student be
a good Scheme programmer, as to be able to understand the principles
behind programming and computers.
About 2 years ago, I posted a similar query to this newsgroup. I
received responses from, among others, MIT, UCLA, UC Berkeley, Brandeis,
the University of Delaware, and Indiana. As a result of these highly
positive responses, we at the University of British Columbia decided to
move our first year computer science courses to this curriculum. We've
been teaching a prototype section this year, and it has gone quite well
(we've learned lots of things *not* to do, too!).
We propose to do what is done in one term at MIT in two terms here (our
students are good, but not as good as MIT students). We will, however,
add a final unit, which introduces Pascal. We are doing this for
pragmatic reasons (a knowledge of Pascal is useful in further computer
science), and for intellectual ones (Pascal takes a rather different--I
would say ``inferior''--view of types from that which Scheme takes, as
the Instructor's Guide to Abelson & Sussman points out). Naturally, the
laboratory project for that part of the course will be to write a Scheme
evaluator in Pascal.
In answer to the question which was posed, I don't support using Scheme
as a replacement for Pascal in an introductory programming course.
What is needed instead is to replace introductory programming by
introductory computer science; Scheme is an excellent vehicle for that.
--
\ Vincent Manis <manis@cs.ubc.ca> "There is no law that vulgarity and
\ Department of Computer Science literary excellence cannot coexist."
/\ University of British Columbia -- A. Trevor Hodge
/ \ Vancouver, BC, Canada V6T 1W5 (604) 228-2394
------------------------------
Message-ID: <9790@medusa.cs.purdue.edu>
Date: 20 Feb 90 22:28:57 GMT
From: Gerald Baumgartner <gb@purdue.edu>
To: scheme@mc.lcs.mit.edu
Subject: problems/risks due to programming language, stories requested
For a research project I am collecting information about the risk of
choosing the wrong programming language. In particular I am looking
for problems that could have been avoided if another (a better)
programming language would have been used.
I know of these three such stories:
1. There is the famous story that a Mariner probe got lost
because of the Fortran statement `DO 3 I = 1.3' (1.3 instead
of 1,3) (see Peter Neumann: A Few Old War Stories Reappear.
ACM SIGSOFT 11(5), Oct. 1986, pp. 16-18). It is a nice story
but, as far as I know, NASA used Jovial at that time and not
Fortran.
2. One of the security holes the Internet Worm took advantage of
was in fingerd (the finger deamon). The deamon uses the gets
routine for input. This routine, written in C, reads input
without checking for bounds on the buffer involved. By
overrunning the buffer, the worm rewrote the stack frame (see
Eugene H. Spafford: Crisis and Aftermath. Communications of
the ACM 32(6), June 1989).
There would be no security hole in the finger daemon if a
programming language would have been used for the I/O
routines, where the compiler takes care of boundary checks for
arrays. Pascal doesn't work since variable length strings are
needed, but Ada would be fine. A language a la ML, where these
checks are done at compile time, would be even better.
3. The AT&T breakdown a month ago was caused by a break statement
in C. See the following mail (multiple forwarding headers deleted):
Subject: AT&T software problem
Subject: Cautionary note on C programming...AT&T learns from experience
>From: kent@wsl.dec.com
Subj: I've always thought C looked like line noise.
Subj: the bug
Subj: AT&T's bug, for you C users out there...
Subj: I C what they mean!
Subj: "c" considered dangerous to telephones
Subj: Be careful from where you break! (else no long distance calls will make it thru...)
Subj: C switch breaks AT&T switches!
Subj: your "c users" list might appreciate this....
I received the following on AT&T's famous bug (and have deleted multiple
forwarding headers):
| | Subject: AT&T Bug
| | Date: Fri Jan 19 12:18:33 1990
| |
| | This is the bug that cause the AT&T breakdown
| | the other day (no, it wasn't an MCI virus):
| |
| | In the switching software (written in C), there was a long
| | "do . . . while" construct, which contained
| | a "switch" statement, which contained
| | an "if" clause, which contained a
| | "break," which was intended for
| | the "if" clause, but instead broke from
| | the "switch" statement.
| |
Again it looks like this bug wouldn't have occurred in another
programming language.
You C what I mean? Do you know other stories like these, if possible
with references? I don't want to praise Ada or pick at C and Fortran;
I am looking for any story where a proveably inappropriate/insecure
programming language has been used.
Gerald Baumgartner gb@cs.purdue.edu ...!{decwrl,gatech,ucbvax}!purdue!gb
------------------------------
Message-ID: <5144@brazos.Rice.edu>
Date: 20 Feb 90 23:54:56 GMT
From: Dorai Sitaram <helma!dorai@rice.edu>
To: scheme@MC.lcs.mit.edu
Subject: Re: comp.lang.functional
In article <1797@skye.ed.ac.uk> jeff@aiai.UUCP (Jeff Dalton) writes:
>In article <1619@husc6.harvard.edu> carlton@husc4.harvard.edu (david carlton) writes:
>>
>>What do people think about creating a comp.lang.functional news groups, for
>>the discussion of functional programming languages?
>
>I'm in favor. Indeed, I was surprised that there wasn't such a group
>already. The only problem would be if we later wanted a ML group,
>say. Should it have to be comp.lang.functional.ml?
I'm tentatively in favor too; however, "functional" is about the most
ambivalent, and consequently useless, term in programming languages.
The two common (often incompatible) views seem to be
i) A language which has higher-order functions;
ii) Ditto, but which very definitely eschews "assignment."
In apparent contrast, "imperative" languages support "assignment," and
are perceived oftentimes, why, I don't know, as definitely having no
higher-order functions (procedures).
Thus we have the paradox of Scheme and ML being both "imperative"
("non-functional," taking definition ii)) as well as "functional"
(taking definition i)).
It may be we should choose another name.
--dorai
--
------------------------------------------------------------------------------
It may be that the gulfs will wash us down;
It may be we shall touch the Happy Isles.
------------------------------------------------------------------------------
------------------------------
End of Scheme Digest
********************
∂22-Feb-90 0521 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #308
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Feb 90 05:21:34 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA23164; Thu, 22 Feb 90 08:19:39 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Thu, 22 Feb 90 08:18:30 est
Received: by mintaka.lcs.mit.edu id ab00631; 22 Feb 90 7:41 EST
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa20035;
22 Feb 90 6:01 EST
Message-Id: <DIGEST.184.900222.030928.17@MC.LCS.MIT.EDU>
Date: 22 Feb 90 03:09:28 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #308
Scheme Digest #308 22 Feb 90 03:09:28 EST
Today's Topics:
syntax question
Scheme Digest #307 (2 messages)
Sun4 Scheme
Scheme and the Art of Programming
----------------------------------------------------------------------
Message-ID: <9002211212.AA08829@tub.UUCP>
Date: Wed, 21 Feb 90 13:12:38 +0100
From: Oliver Laumann <net%TUB.BITNET@mitvma.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: syntax question
[Warning: this message is not about #f and '()]
I would like to know how something like foo'bar or foo`bar should be
tokenized by a Scheme parser. That is, is it parsed as a single token,
or are quote and backquote regarded as delimiters?
I think the formal syntax description in the R↑3.99RS is not particularly
clear on this point. It says "[identifiers] may be terminated by any
<delimiter>, but not necessarily by anything else". However, quote and
backquote are not listed in the rule for <delimiter>.
Regards,
--
Oliver Laumann net@TUB.BITNET net@tub.cs.tu-berlin.de net@tub.UUCP
------------------------------
Message-ID: <9002211840.aa24798@mintaka.lcs.mit.edu>
Date: Wed, 21 Feb 90 17:39 CST
From: RKIRCHNE@carleton.edu
To: Scheme@MINTAKA.LCS.MIT.EDU
Subject: RE: Scheme Digest #307
Can I unsubscribe from the Digest and resubscribe to get the original
messages? Thanks. Roger Kirchner
------------------------------
Message-ID: <703508.900221.DEVON@AI.AI.MIT.EDU>
Date: Wed, 21 Feb 90 21:04:55 EST
From: Devon Sean McCullough <DEVON%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU>
Reply-To: devon@ai.ai.mit.edu
To: comp.lang.scheme@EDDIE.MIT.EDU, scheme@MC.LCS.MIT.EDU
CC: DEVON%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU
Subject: Sun4 Scheme
Do you know of a commercial Scheme with a good compiler for Sun's sparc?
I told <> to imbed Scheme in their <> but they want commercial support.
------------------------------
Message-ID: <9002211840.aa24798@mintaka.lcs.mit.edu>
Date: 21 Feb 90 23:39:00 GMT
From: CARLETON.EDU!RKIRCHNE@bloom-beacon.mit.edu
To: scheme@mc.lcs.mit.edu
Subject: RE: Scheme Digest #307
Can I unsubscribe from the Digest and resubscribe to get the original
messages? Thanks. Roger Kirchner
------------------------------
Message-ID: <36655@iuvax.cs.indiana.edu>
Date: 22 Feb 90 02:51:38 GMT
From: Pete Harlan <silver!harlan@iuvax.cs.indiana.edu>
To: scheme@mc.lcs.mit.edu
Subject: Scheme and the Art of Programming
manis@cs.ubc.ca (Vincent Manis) writes:
>The classical way to introduce computer science via Scheme is Abelson
>and Sussman's `Structure and Interpretation of Computer Programs',
>published by MIT Press/McGraw-Hill. Paradoxically, this book is not
>about Scheme, and hardly mentions it. Instead, the book concentrates
>upon fundamental principles of computer science, paradigms of program
>design, and the structures of various evaluators, including interpreters
>and compilers for Scheme. The goal isn't so much to have the student be
>a good Scheme programmer, as to be able to understand the principles
>behind programming and computers.
And now of course there is also Springer and Friedman's _Scheme and
the Art of Programming_, also published by MIT Press/McGraw-Hill. The
difference between these two excellent books is best summed up I think
in the difference between their titles. For a study of programming
language issues I would prefer Abelson and Sussman, and for learning
the elements of programming I would prefer Springer and Friedman.
The early sections of the book provide a beautiful development of
recursion/iteration and data abstraction. This is followed by an
amazing two chapters on higher-order procedures that completes the
development of "how to write programs". In this way the first ~250
pages of the book prepare the student for the topics in the final ~350
pages.
Part 3, Managing State, begins with a functional view of vectors, and
then introduces the reader to mutation by showing the efficiency
gained through mutable vectors vs. functional ones. The two views of
vectors are then compared throughout the discussion of sorting
techniques.
The following section on mutation presents not only the use of
mutation the way it is typically used in Scheme (eg, memoization), but
also includes a section on imperative-style programming. The chapter
concludes with a lovely set of exercises that has the student
implement Turing machines as a controller driven by an external
state-transition table. One could hardly imagine a more fitting
conclusion for a chapter on mutation!
Having given the reader the ability to mutate data, the book then
presents a controllable use for such ability with object-oriented
programming. Objects are then used to introduce the basic abstract
data structures (accumulators, stacks, queues, buckets and hash
tables) while showing how they incorporate elements of each other.
This is followed by an extended OOP example, a gas-station simulation
that finishes the section on managing state. To be fair, I must say I
thought this simulation got a little bogged down -- spread over so
many pages, it requires a diligent reader to follow the discussion.
A section on syntactic extension comes next, catering to both the
traditional "macro" declaration and extend-syntax. Having gained the
power to declare special forms, the book defines streams, developing
recursive data, and ends with an extended example for reformatting a
text file using filters.
"Control" is the title of Part 5, the last section of the book. This
is a thorough development of the nature of run-time control, and the
capturing of run-time control through the use of call/cc. The first
chapter develops call/cc, and the second chapter uses it to implement
coroutines. While the development is careful and the examples lucid,
some of the exercises here are treacherous indeed!
Overall, the book is an excellent introduction to computer programming
and computer science, with excursions into specific areas to provide
applications of what is being learned. Having read it cover-to-cover,
I couldn't recommend it more highly as a first computer-science text.
Pete Harlan
Indiana University
harlan@silver.ucs.indiana.edu
Disclaimer: I am being as objective as I can about a book I fell in
love with while reading. The authors of the book are on faculty here,
but should you doubt my review of the book, _read_ it! I learned
Scheme from _Structure and Interpretation of Computer Programs_, and
have similar accolades for it as a book about interpretation models.
Where the two books overlap, it is a tossup -- Abelson/Sussman favors
the advanced programmer, while Springer/Friedman favors the
development of technique.
------------------------------
End of Scheme Digest
********************
∂23-Feb-90 0103 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #309
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Feb 90 01:03:10 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA10959; Fri, 23 Feb 90 03:57:03 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Fri, 23 Feb 90 03:56:09 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa29320;
23 Feb 90 3:33 EST
Message-Id: <DIGEST.184.900223.025428.23@MC.LCS.MIT.EDU>
Date: 23 Feb 90 02:54:27 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #309
Scheme Digest #309 23 Feb 90 02:54:27 EST
Today's Topics:
first programming languages, and second ones too
----------------------------------------------------------------------
Message-ID: <9002221434.AA03515@schizo.samsung.com>
Date: Wed, 21 Feb 90 09:39:47 EDT
From: gjc@mitech.com
Reply-To: gjc@mitech.com
To: scheme@mc.lcs.mit.edu
Subject: first programming languages, and second ones too
There are more obvious practical and commercial advantages to knowing
the language C rather than Pascal, so I would think students would be
better served learning and using that language as a second language
after Scheme.
* with a reasonable ANSI compiler supporting prototypes, and especially one
that supports a "require-prototypes" compilation flag, it seems you get
about as much strict type checking out of a C program as out of an equivalent
program in Pascal.
* C has more modern/natural I/O primitives, not the funny ancient mainframe
O/S oriented stuff in standard Pascal.
* you can build up complex programs and datastructures from "the bits" and
abstract upwards in the same way you learn in lisp programming. Obviously
just about any language lets you do this; I'm just arguing that it is rather
natural and similar in lisp and C.
* one could introduce/motivate C near the end of a course (e.g. Chapter 5, SICP)
with a small C program that implements Scheme, such as SIOD.
On the other hand, after SICP, especially chapter 5, one could argue more
strongly that it would be more natural to cover a reasonable assembly
language programming machine environment in more detail rather than go
for something artificial like a so-called high-level language.
I had one student at Boston University that got into CADR microcode after
his lisp course.
-gjc
------------------------------
End of Scheme Digest
********************
∂23-Feb-90 1036 ramsdell@linus.mitre.org Re: Module proposal [long]
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Feb 90 10:36:25 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA17510; Fri, 23 Feb 90 13:29:13 EST
Received: from linus.mitre.org (linus.mitre.org) by zurich.ai.mit.edu; Fri, 23 Feb 90 13:25:37 est
Received: from huxley.mitre.org by linus.mitre.org (5.61/RCF-4S)
id AA27790; Fri, 23 Feb 90 13:22:09 -0500
Posted-Date: Fri, 23 Feb 90 13:22:04 EST
Received: by huxley.mitre.org (5.61/RCF-4C)
id AA11803; Fri, 23 Feb 90 13:22:05 -0500
From: ramsdell@linus.mitre.org
Message-Id: <9002231822.AA11803@huxley.mitre.org>
To: rrrs-authors@zurich.ai.mit.edu
Subject: Re: Module proposal [long]
In-Reply-To: Your message of Tue, 20 Feb 90 00:37:42 -0500.
<9002200537.AA04375@brokaw.LCS.MIT.EDU>
Date: Fri, 23 Feb 90 13:22:04 EST
[This is in reply to James R. Rauen's Module System Proposal.]
The proposal represents a significant contribution. It is certainly
better that Common Lisp's packages. Before I form an opinion on this
proposal, please answer the following question. Many module systems
provide some sort of generic or parameterized module facility.
Standard ML has functors and Ada has generics. Does this proposal
provide parametric modules and can they be instantiated using a set of
mutually recursive module declarations? If parameterized modules were
left out purposely, please explain why.
John
∂24-Feb-90 0134 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #310
Received: from life.ai.mit.edu ([128.52.32.80]) by SAIL.Stanford.EDU with TCP; 24 Feb 90 01:34:30 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA28796; Sat, 24 Feb 90 04:31:32 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Sat, 24 Feb 90 04:30:32 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa00562;
24 Feb 90 3:20 EST
Message-Id: <DIGEST.184.900224.023929.28@MC.LCS.MIT.EDU>
Date: 24 Feb 90 02:39:28 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #310
Scheme Digest #310 24 Feb 90 02:39:28 EST
Today's Topics:
A Report on Object-oriented Programming in Scheme.
first programming languages, and second ones too
Scheme->C compiler available via FTP
problems/risks due to programming language, stories requested
----------------------------------------------------------------------
Message-ID: <1990Feb23.095548.2764@iesd.auc.dk>
Date: 23 Feb 90 09:55:48 GMT
From: Kurt Normark <eru!luth!sunic!dkuug!iesd!normark@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: A Report on Object-oriented Programming in Scheme.
I use Abelson and Sussman's book "Structure and Interpretation of
Computer Programs" in a course on Scheme and programming paradigms.
One of the things I find particular interesting is the possibilities
of simulating object-oriented mechanisms in Scheme. Unfortunately,
the Abelson and Sussman book is relatively weak in the object-oriented area.
I have written a report which introduces object-oriented programming
in Scheme. It starts with the basics (in order to be pedagogical),
but it also describes some more advanced topics such as multiple
super classes, metaclasses, and procedural activation of methods.
Some of the topics are inspired of existing literature
(in particular Adams and Rees' paper "Object-oriented programming in Scheme",
Lisp & Functional programming 88); other material is new (as far as
I know).
Seriously interested people can obtain a copy of the report (send me a
message). The title and the table of contents of the report is listed
below.
Kurt Normark
normark@iesd.auc.dk
Kurt Normark:
"SIMULATION OF OBJECT-ORIENTED CONCEPTS AND MECHANISMS IN SCHEME",
R-90-1, Department of Mathematics and Computer Science,
Institute of Electronic Systems, Aalborg University, Denmark.
1. Introduction
1.1 Scheme
1.2 Simulation
1.3 Related Work
1.4 Outline of this Report
2. Classes, Instances, and Message Passing
2.1 Classes and Instances
2.2 Message Passing
2.3 Procedural Activation of Methods
3. Class Hierarchies and Single Inheritance
3.1 The Introduction of super
3.2 Object Precedence Lists
3.3 Another Interpretation of self
4. Multiple Inheritance
4.1 A Simple Approach
4.2 Shared Object Parts
4.3 The Object Precedence List Representation
4.4 Method Combination
4.5 Caching of Effective Methods
5. Metaclasses
5.1 The pattern of Metaclasses
5.2 The most General Parts of the Class Hierarchy
5.3 Instantiation of Classes via Message Passing
5.4 Support of Metaprogramming
6. Conclusions
------------------------------
Message-ID: <6914@ubc-cs.UUCP>
Date: 24 Feb 90 02:56:56 GMT
From: Vincent Manis <ubc-cs!manis@beaver.cs.washington.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: first programming languages, and second ones too
I don't want to get too far away from the purpose of this newsgroup, but
I wouldn't recommend C as an immediate successor to Scheme in a
SICP-based course. The major reasons are the convoluted syntax and the
lack of reasonable response to run-time errors. I've taught courses
using C at the second and third year levels for years, and I know for a
fact that students find both of these almost insuperable.
I am, however, in agreement with gjc that the right way to teach these
languages is by having the students work on a Scheme evaluator. That's
certainly what we had in mind.
As for going directly to assembler: in our course, we won't be using the
approach SICP uses to assembly language. We're going to introduce a
fairly conventional hypothetical machine, and then explain its behaviour
on the register transfer level. This seems more appropriate than the
SIPC one in a course which is aimed at non-electrical engineers.
--
\ Vincent Manis <manis@cs.ubc.ca> "There is no law that vulgarity and
\ Department of Computer Science literary excellence cannot coexist."
/\ University of British Columbia -- A. Trevor Hodge
/ \ Vancouver, BC, Canada V6T 1W5 (604) 228-2394
------------------------------
Message-ID: <2886@bacchus.dec.com>
Date: 23 Feb 90 23:08:29 GMT
From: Joel Bartlett <decwrl.dec.com!bartlett@decwrl.dec.com>
To: scheme@mc.lcs.mit.edu
Subject: Scheme->C compiler available via FTP
The Scheme-to-C compiler, Scheme->C, done at Digital Equipment
Corporation's Western Research Laboratory is now available for public
ftp.
The compiler compiles Revised**3 Scheme to C that is then compiled by
the native C compiler for the target machine. This design results in
a portable system that allows either stand-alone Scheme programs or
programs written in both compiled and interpreted Scheme and other
languages.
The Scheme->C system supports the essentials of Revised**3 and many
of the optionals. Extensions include "expansion passing style"
macros, a foreign function call capability, and interfaces to X11's
Xlib. The system does provide call-with-current-continuation.
Numbers are represented internally as 29-bit integers, or 64-bit
floating point values.
The compiler is written in Scheme. Most of the runtime system
(including an interpreter) is written in Scheme. The generational
compacting garbage collector and a few other things are written in C.
There is a small (< 100 lines) amount of assembly code. The system
is known to run on VAX's and DECstation 3100's running Ultrix. Other
ports should be straightforward.
The system is available for anonymous ftp from 'gatekeeper.dec.com'
[16.1.0.2]. The Scheme->C files are in '/pub/DEC/Scheme-to-C'. Those
files include:
README - overview and copyright notice.
23feb90.tar.Z - compressed tar file containing all source
and documentation.
Joel Bartlett bartlett@decwrl.dec.com
------------------------------
Message-ID: <1990Feb24.001350.2617@sq.sq.com>
Date: 24 Feb 90 00:13:50 GMT
From: Mark Brader <mintaka!ogicse!uwm.edu!cs.utexas.edu!jarvis.csri.toronto.edu!utgpu!utzoo!sq!msb@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: problems/risks due to programming language, stories requested
Gerald Baumgartner (gb@cs.purdue.EDU) writes in many groups:
> There is the famous story that a Mariner probe got lost
> because of the Fortran statement `DO 3 I = 1.3' (1.3 instead
> of 1,3) ... It is a nice story but, as far as I know, NASA used
> Jovial at that time and not Fortran.
Just for the record, the above was definitively shown to be fictional
according to authoritative references given in comp.risks (= Risks Digest),
issue 9.75 (I hear), not too many months ago. There is at least one
textbook that states it as truth; this is wrong. The actual reason for
the loss of Mariner I was an error in code used in recovering from a
hardware failure; the code had been based on handwritten equations, and
in transcribing one of these, an overbar was deleted from one letter.
A story which may have been the true origin of the "DO statement myth"
was posted fairly recently in alt.folklore.computers; the article
cited a program at NASA that did enter production use with a dot-for-comma
bug in a DO statement, but it wasn't a spacecraft flight control program.
(I didn't save the details and would be happy to see them again.)
Followups directed to alt.folklore.computers.
--
Mark Brader "I'm not going to post a revision: even USENET
utzoo!sq!msb, msb@sq.com readers can divide by 100." -- Brian Reid
This article is in the public domain.
------------------------------
End of Scheme Digest
********************
∂25-Feb-90 0020 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #311
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 25 Feb 90 00:20:20 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA05840; Sun, 25 Feb 90 03:15:37 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Sun, 25 Feb 90 03:14:42 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa20544;
25 Feb 90 2:42 EST
Message-Id: <DIGEST.184.900225.022432.31@MC.LCS.MIT.EDU>
Date: 25 Feb 90 02:24:31 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #311
Scheme Digest #311 25 Feb 90 02:24:31 EST
Today's Topics:
free Scheme interpreter
----------------------------------------------------------------------
Message-ID: <22377@pasteur.Berkeley.EDU>
Date: 24 Feb 90 07:46:56 GMT
From: Jonathan Lee <pasteur!swindle!jonathan@ucbvax.berkeley.edu>
To: scheme@mc.lcs.mit.edu
Subject: free Scheme interpreter
Fools' lisp is a Scheme interpreter that follows all the RRRRS
essentials and is reasonably small. It is written in C and Scheme.
The design allows easy inclusion of new datatypes and primitives.
It is available from scam.berkeley.edu (128.32.138.1) via anonymous
ftp in src/local/fools.tar.Z (a compressed tar file, so remember to
turn on binary mode).
The interpreter runs on the following systems (it will probably run
on any 4.3BSD based UNIX with little trouble):
DECstation 3100 Ultrix 3.1
Sun3 and Sun4 SunOS 4.0.3
VAX Ultrix 3.1 and 4.3BSD
Sequent Symmetry DYNIX(R) V3.0.12
Apollo DN3500 DomainOS Release 10.1 (bsd4.3)
Let me know if you pick up a copy, and feel free to send me any
comments.
Thanks,
Jonathan Lee (jonathan@scam.berkeley.edu)
------------------------------
End of Scheme Digest
********************
∂26-Feb-90 0111 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #312
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 26 Feb 90 01:11:38 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA13335; Mon, 26 Feb 90 03:49:22 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Mon, 26 Feb 90 03:48:29 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa14691;
26 Feb 90 3:25 EST
Message-Id: <DIGEST.184.900226.030945.33@MC.LCS.MIT.EDU>
Date: 26 Feb 90 03:09:45 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #312
Scheme Digest #312 26 Feb 90 03:09:45 EST
Today's Topics:
parallel multilisp? (2 messages)
----------------------------------------------------------------------
Message-ID: <11300001@altair>
Date: 23 Feb 90 21:35:00 GMT
From: deimos!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!auriga!altair!boyle@rutgers.edu
To: scheme@mc.lcs.mit.edu
Subject: parallel multilisp?
I'm not sure this is the best place to ask, but I'll do so anyway. Is
there a parallel implementation of Multilisp available for the Encore,
Sequent, or Alliant? If so, could someone please tell me how to
obtain it?
Jim Boyle
boyle@mcs.anl.gov
------------------------------
Message-ID: <17047@cs.yale.edu>
Date: 25 Feb 90 20:28:19 GMT
From: Duke Briscoe <cs.yale.edu!briscoe-duke@yale-zoo.arpa>
To: scheme@mc.lcs.mit.edu
Subject: Re: parallel multilisp?
I posted this information just about a week ago, but here it is again.
From masala.lcs.mit.edu (18.27.0.200) in the pub directory you can get
a T dialect extended for parallelism (uses the future construct)
called Mul-T; it runs on the Encore Multimax. In case you don't know,
T is pretty similar to Scheme, and in fact T supports an environment
which conforms to the Scheme standard.
------------------------------
End of Scheme Digest
********************
∂26-Feb-90 0929 jar@zurich.ai.mit.edu list of implementations
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 26 Feb 90 09:29:24 PST
Received: from zurich.ai.mit.edu ([18.43.0.158]) by life.ai.mit.edu (4.0/AI-4.10) id AA16292; Mon, 26 Feb 90 11:32:46 EST
Received: from localhost by zurich.ai.mit.edu; Mon, 26 Feb 90 11:31:20 est
Date: Mon, 26 Feb 90 11:31:20 est
From: jar@zurich.ai.mit.edu (Jonathan Rees)
Message-Id: <9002261631.AA01215@zurich.ai.mit.edu>
To: rrrs-authors@zurich.ai.mit.edu
Cc: pg@litp.ibp.fr, jdf@litp.ibp.fr
Subject: list of implementations
I'm still maintaining a list of available Scheme implementations.
Before I re-announce its existence on the Scheme list, I thought I'd
send a message here asking implementors to check to make sure that the
information in the file is up to date. The file is
zurich.ai.mit.edu: pub/scheme/scheme-impls.txt
It has information on:
MacScheme 1-7-87
PC Scheme 11-12-85
MIT Scheme 1-17-90
T 1-16-87
Chez Scheme 10-30-87
Elk 1-17-90
Scheme->C 1-11-89
skim 12-27-87
SIOD 6-8-88
Pseudoscheme 1-16-90
Scheme84 ?-?-85
Vincennes Scheme ?-?-85
If you do want to revise an entry, please mail me a new version. Try
to keep entries under 60 lines.
If anyone has information on any other implementations, particularly
XScheme, please let me know.
Jonathan
∂26-Feb-90 1857 @zurich.ai.mit.edu,@mc.lcs.mit.edu:chaynes@iuvax.cs.indiana.edu results of the poll
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 26 Feb 90 18:57:34 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA29140; Mon, 26 Feb 90 21:52:03 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Mon, 26 Feb 90 21:51:03 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa03611;
26 Feb 90 21:48 EST
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 26 Feb 90 21:49:56 EST
Received: from [129.79.254.192] by mintaka.lcs.mit.edu id aa03299;
26 Feb 90 21:43 EST
Received: by iuvax.cs.indiana.edu
Date: Mon, 26 Feb 90 21:43:18 -0500
From: Chris Haynes <chaynes@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu, scheme-standard@wheaties.ai.mit.edu
Subject: results of the poll
Message-Id: <9002262143.aa03299@mintaka.lcs.mit.edu>
The poll on the following alternatives:
A. #F and () may be identical, and () may be false;
B. #F and () may be identical, but () is true if they are distinct;
C. #F and () are distinct, and () may be false;
D. #F and () are distinct, and () is true.
has yielded the following tally:
prefer strongly oppose
A 2 6
B 2 4
C 0 8
D 20 2
none 11
Since there is a clear preference for D, and little opposition to it,
the mandate for the editors is clear.
∂27-Feb-90 1628 @zurich.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu (not (eq? '() #f))
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 27 Feb 90 16:28:36 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA00455; Tue, 27 Feb 90 19:13:29 EST
Received: from skinner.cs.uoregon.edu (skinner.cs.uoregon.edu) by zurich.ai.mit.edu; Tue, 27 Feb 90 19:12:11 est
Received: from spencer.cs.uoregon.edu by skinner.cs.uoregon.edu with SMTP
(5.61.14/IDA-1.2.8) id AA26277; Tue, 27 Feb 90 16:11:48 -0800
Received: by spencer.cs.uoregon.edu; Tue, 27 Feb 90 16:13:52 PST
Date: Tue, 27 Feb 90 16:13:52 PST
From: will@cs.uoregon.edu
Message-Id: <9002280013.AA23008@spencer.cs.uoregon.edu>
To: rrrs-authors@zurich.ai.mit.edu
Subject: (not (eq? '() #f))
The poll conducted by Chris Haynes has revealed that the status
quo is opposed by more people and supported by far fewer people
than option D (that #F is distinct from the empty list, and the
empty list counts as true in boolean contexts). Since unanimity
cannot be achieved, option D appears to be the next best thing.
I will therefore change the R3.99RS to reflect option D by making
the changes indicated below. These changes will make R4RS
consistent with the draft IEEE standard.
Peace, Will
section 3.2
Change: except for #f and possibly the empty list.
To: except for #f.
Delete the two sentences that follow this one.
Change: to refer to any Scheme value that counts as true
To: to refer to any Scheme value except #f
Change: to refer to any Scheme value that counts as false.
To: to refer to #f.
section 3.4
Add null? to the list of predicates, and add emptylist
to the list of types.
section 6.1
Rephrase first two paragraphs as
The standard boolean objects for true and false are
written as #t and #f. What really matters, though,
are the objects that the Scheme conditional expressions
(if, cond, and, or, do) treat as true or false. Of all
the standard Scheme values, only #f counts as false in
conditional expressions. All other standard Scheme
values, including #t, pairs, the empty list, symbols,
numbers, strings, vectors, and procedures, count as true.
Eliminate the rationale for allowing the empty list to
count as false.
Change the following examples as indicated:
(not '()) ==> #f
(not (list)) ==> #f
(boolean? '()) ==> #f
section 6.2
Change: , except that #f and the empty list are permitted
to be identical.
To: .
section 6.3
Remove the note that follows the description of null?
Notes: Language changes
Add: The empty list is now required to be distinct from #f
and to count as true in conditional expressions.
∂28-Feb-90 0824 jmiller@chaos.cs.brandeis.edu (not (eq? '() #f))
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 28 Feb 90 08:24:26 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA19839; Wed, 28 Feb 90 11:15:29 EST
Received: from chaos (chaos.cs.brandeis.edu) by zurich.ai.mit.edu; Wed, 28 Feb 90 11:14:08 est
Received: by chaos Wed, 28 Feb 90 11:14:23 -0500
Date: Wed, 28 Feb 90 11:14:23 -0500
From: "Jim Miller" <jmiller@chaos.cs.brandeis.edu>
Message-Id: <9002281614.AA00732@chaos>
To: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Guillermo J. Rozas's message of Tue, 27 Feb 90 20:31:39 est <9002280131.AA13188@zurich.ai.mit.edu>
Subject: (not (eq? '() #f))
Reply-To: JMiller@chaos.cs.brandeis.edu
Will,
It doesn't seem reasonable to me that you have chosen to act
unilaterally in the RnRS forum. The poll is in accordance with IEEE
rules for a standard, but definitely not in the consensus-seeking
environment of RnRS. I, personally, oppose the change in RnRS.
As an editor of IEEE P1178/D4, I will abide by the results of the poll
IN THAT FORUM. In that role, I appreciate the careful list of changes
you have provided. Chris Hanson and I will most likely put them
directly into P1178/D4.
--Jim Miller
∂01-Mar-90 1416 @zurich.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu (maybe (eq? '() #f))
Received: from life.ai.mit.edu ([128.52.32.80]) by SAIL.Stanford.EDU with TCP; 1 Mar 90 14:16:23 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA00250; Thu, 1 Mar 90 17:11:40 EST
Received: from skinner.cs.uoregon.edu (skinner.cs.uoregon.edu) by zurich.ai.mit.edu; Thu, 1 Mar 90 17:10:22 est
Received: from spencer.cs.uoregon.edu by skinner.cs.uoregon.edu with SMTP
(5.61.14/IDA-1.2.8) id AA15852; Thu, 1 Mar 90 14:09:55 -0800
Received: by spencer.cs.uoregon.edu; Thu, 1 Mar 90 14:11:54 PST
Date: Thu, 1 Mar 90 14:11:54 PST
From: will@cs.uoregon.edu
Message-Id: <9003012211.AA03105@spencer.cs.uoregon.edu>
To: rrrs-authors@zurich.ai.mit.edu
Subject: (maybe (eq? '() #f))
It doesn't seem reasonable to me that you have chosen to act
unilaterally in the RnRS forum. The poll is in accordance with IEEE
rules for a standard, but definitely not in the consensus-seeking
environment of RnRS....
Upon reflection, I agree: I have acted unreasonably, and I
apologize to the RnRS authors for taking it upon myself to
make a substantive change without a unanimous mandate from
the authors. I regret any bad feelings caused by this most
recent example of my high-handedness, of which I repent and
ask to be forgiven.
Rather than leave the wording of the R3.99RS as is, I would like
to go ahead and make the changes listed in my recent message but
add the following paragraph to section 3.2:
For historical reasons some implementations regard #f and the
empty list as the same object. Such implementations therefore
cannot make the empty list count as true, nor can they satisfy
all the requirements of sections 3.4 and 6.1.
This paragraph, modelled on the rationale in section 6.1 of the
R3.99RS, effectively negates the other changes. The changes would
therefore be a matter of editorial emphasis instead of substance.
The point would be to collect the scattered exceptions ("waffles")
occasioned by this issue into a single paragraph. Cosmetically,
this would also minimize the apparent differences between the R4RS
and the IEEE standard.
I would welcome any opinions you may have on whether such editorial
changes are desirable or undesirable. Please send your opinions
directly to me so they will not be seen by those that don't want
to see them. Let me take this opportunity to promise those who
are still reading this that the macro proposal will soon give you
something more interesting to think about.
Peace, Will Clinger
∂01-Mar-90 1641 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #313
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Mar 90 16:41:31 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA19548; Thu, 1 Mar 90 03:51:42 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Thu, 1 Mar 90 03:50:29 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa17643;
1 Mar 90 3:25 EST
Message-Id: <DIGEST.184.900301.023259.7@MC.LCS.MIT.EDU>
Date: 1 Mar 90 02:32:59 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #313
Scheme Digest #313 1 Mar 90 02:32:59 EST
Today's Topics:
A Franz Lisp question. (2 messages)
Functional / algebraic languages for DS3100
first programming languages, and second ones too
Scheme and the Art of Programming
problems/risks due to programming language, stories requested (3 messages)
Scheme->C compiler available via FTP
Scheme as 1st language
A Report on Object-oriented Programming in Scheme.
----------------------------------------------------------------------
Message-ID: <660@shuldig.Huji.Ac.IL>
Date: 25 Feb 90 16:01:07 GMT
From: shum.huji.ac.il!misha@ucbvax.berkeley.edu
To: scheme@MC.lcs.mit.edu
Subject: A Franz Lisp question.
As a novice to Franz Lisp, I have the following question:
As you all might well know, Franz Lisp is a dynamic binding langauge, while
Scheme is not. Therefore, the following code is unwriteable in Franz Lisp:
(Scheme):
(define (func param)
(lambda (x) (param x)))
[This function accepts a parameter which is also a function, and returns yet
another function which 'apply's param on x.]
Am I right? And if I am not, how is it done then?
Thanks,
Misha.
------------------------------
Message-ID: <3417@undis.cs.chalmers.se>
Date: 26 Feb 90 14:00:49 GMT
From: Lennart Augustsson <mcsun!sunic!chalmers!cs.chalmers.se!augustss@uunet.uu.net>
To: scheme@mc.lcs.mit.edu
Subject: Re: Functional / algebraic languages for DS3100
In article <1990Feb14.190515.4402@ncsuvx.ncsu.edu> jwb@cepmax.ncsu.edu writes:
>Apparently NJML is soon to be released for the pmax. My
>question is `Are there any (currently available) alternatives?'
>By alternatives I mean a `modern' functional language with
>disjoint union data constructors, pattern matching, etc.
>
Yes, there are alternativers (at leaast one). LML is available for
pmax. You can get lml by (anonymous) ftp from skutt.cs.chalmers.se.
It's in the file pub/lml-0.95a.tar.Z.
Below is a short blurb on LML.
There will be a new release of LML available in a few weeks, but only
with minor differences.
-- Lennart Augustsson
New LML release (0.95)
======================
There is now a new version of the LML compiler available. It is,
naturally, free of charge. The best way (both for us and for you) to
get a copy is via anonumous ftp to skutt.cs.chalmers.se (129.16.2.7)
where it is stored in pub/lml-0.95a.tar.Z. Uncompress, untar, install,
and enjoy. If you don't have access to the Internet and you don't
know anyone who has a copy of LML you can send us a tape or cartridge
and we'll put LML on. This process takes time, since it involves
tedious work for us. If you ftp a copy or get it from someone else,
please send us (electronic) mail message and tell us so! It's nice to
know who has it.
The distribution take a lot of space. Around 15 Mbytes in the uncompressed
version. This is because it includes binary files for a lot of machines,
so most of this can be thrown way once you have unpacked it.
This may very well be the last LML version ever! We hope that Haskell
will take over soon.
For those of you who have not heard of LML, here's a short introduction:
LML is a strongly typed, lazy, purely functional language. The LML
system consist of a compiler in the traditional batch-oriented sense.
You give the compiler a file which it compiles and gives you an
executable file. The compiler produces code that is reasonable enough
to write "real" programs, such as the compiler itself. There are also
some primitives for I/O that allows you to write simple real time
programs.
The compiler runs on a number of machines, but only under UNIX (so
far). The machines and OS on which LML runs today are:
SUN3 SunOS 3.5
SUN3 SunOS 4.0
Sequent Symmetry Dynix 3.0.12
Sequent Balance (this version has not been used for a
while, but probably works)
VAX BSD 4.3
IBM RT/PC BSD 4.3
CRAY XMP Unicos
DECstation 3100 Ultrix
SUN4 SunOs 4.0
The distribution contains binaries and source (in LML) for the
compiler and some contributed programs, as well as some documentation.
If you have any problems send us a mail.
Lennart Augustsson Thomas Johnsson
augustss@cs.chalmers.se johnsson@cs.chalmers.se
Department of Computer Sciences
Chalmers University of Technology
S-412 96 Gothenburg
Sweden
--
-- Lennart Augustsson
Email: augustss@cs.chalmers.se
------------------------------
Message-ID: <9002261902.AA01811@joplin.think.com>
Date: Mon, 26 Feb 90 14:02:14 EST
From: Guy Steele <gls@think.com>
To: Scheme@lcs.mit.edu
Subject: first programming languages, and second ones too
Date: Wed, 21 Feb 90 09:39:47 EDT
>From: gjc@mitech.com
There are more obvious practical and commercial advantages to knowing
the language C rather than Pascal, so I would think students would be
better served learning and using that language as a second language
after Scheme.
* with a reasonable ANSI compiler supporting prototypes, and especially one
that supports a "require-prototypes" compilation flag, it seems you get
about as much strict type checking out of a C program as out of an equivalent
program in Pascal.
Hm. And none of that nasty array-bounds checking that costs so
many cycles. Much better to let machines crash or behave strangely.
See, for example, the mailer buffer overflow bug recently discoverec
at Stanford (ACM SIGSOFT Software Engineering Notes 15, 5, January 1990,
page 7, item "Risks of Mail").
* C has more modern/natural I/O primitives, not the funny ancient mainframe
O/S oriented stuff in standard Pascal.
Double hm. You mean like "gets", which made possible parts of the
Morris worm?
...
--Guy :-)
------------------------------
Message-ID: <1844@skye.ed.ac.uk>
Date: 26 Feb 90 17:42:53 GMT
From: Jeff Dalton <mcsun!ukc!edcastle!aiai!jeff@uunet.uu.net>
To: scheme@mc.lcs.mit.edu
Subject: Re: Scheme and the Art of Programming
In article <36655@iuvax.cs.indiana.edu> harlan@silver.ucs.indiana.edu (Pete Harlan) writes:
>concludes with a lovely set of exercises that has the student
>implement Turing machines as a controller driven by an external
>state-transition table. One could hardly imagine a more fitting
>conclusion for a chapter on mutation!
Humm. Turing machines are pretty boring, IMHO.
------------------------------
Message-ID: <BILL.90Feb27143004@hcx2.ssd.harris.com>
Date: 27 Feb 90 19:30:04 GMT
From: Bill Leonard <snorkelwacker!usc!samsung!uakari.primate.wisc.edu!uflorida!novavax!hcx1!bill@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: problems/risks due to programming language, stories requested
In article <9790@medusa.cs.purdue.edu> gb@cs.purdue.EDU (Gerald Baumgartner) writes:
I received the following on AT&T's famous bug (and have deleted multiple
forwarding headers):
| | Subject: AT&T Bug
| | Date: Fri Jan 19 12:18:33 1990
| |
| | This is the bug that cause the AT&T breakdown
| | the other day (no, it wasn't an MCI virus):
| |
| | In the switching software (written in C), there was a long
| | "do . . . while" construct, which contained
| | a "switch" statement, which contained
| | an "if" clause, which contained a
| | "break," which was intended for
| | the "if" clause, but instead broke from
| | the "switch" statement.
| |
Again it looks like this bug wouldn't have occurred in another
programming language.
I can't resist saying that this last statement seems to me to be utter
nonsense. What programming language (read, compiler) can read the
programmer's mind and tell what he meant? The use of the "break" statement
was a logic error (actually, it sounds like it was a lack of knowledge of
the language, since "break" does not apply to "if"). I can't imagine a
programming language that could discern this type of error. [If I use
WHILE instead of IF, for instance, I can expect some things to work and
some not. Yet I seriously doubt any compiler could possibly detect this
error.]
I certainly think programmers often choose an inappropriate language, but I
shy away from anecdotal stories like these because they seem (to me) to
spread a lot of misinformation. Unless you implement a project in multiple
languages, it is nothing more than a guess to say what would have happened
if the project had been implemented in some other language. Perhaps you
would have discovered an even more serious flaw in that language, or you
might simply find it was no better or worse than the one you chose, just
different.
Most of the stories I have heard along these lines all struck me as missing
the point: how well was the program tested? Were there code reviews?
Design reviews? All of these techniques are proven to reduce errors. Most
of the errors in these stories (e.g., the infamous dot-versus-comma one)
should have been found with even rudimentary testing.
Use of an inappropriate language is no excuse for abandoning other techniques
of good software engineering.
--
Bill Leonard
Harris Computer Systems Division
2101 W. Cypress Creek Road
Fort Lauderdale, FL 33309
bill@ssd.csd.harris.com or hcx1!bill@uunet.uu.net
------------------------------
Message-ID: <211@puma.ge.com>
Date: 27 Feb 90 19:32:14 GMT
From: Keith Morgan <cs.utexas.edu!uwm.edu!rpi!crdgw1!ge-dab!puma!rocky!kmorgan@rice.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: Scheme->C compiler available via FTP
In article <2886@bacchus.dec.com> bartlett@decwrl.dec.com (Joel Bartlett) writes:
>The Scheme-to-C compiler, Scheme->C, done at Digital Equipment
>Corporation's Western Research Laboratory is now available for public
>ftp. [...}
>There is a small (< 100 lines) amount of assembly code. The system
>is known to run on VAX's and DECstation 3100's running Ultrix. Other
>ports should be straightforward.
My installation on the Vax went very smoothly. This is a nice system.
However, I really need it for the SPARC. The assembly portion doesn't
look too bad, but the heap manager might be hairy due to the new and
exciting alignment restrictions of the SPARC. Has anyone done this
port or planning to?
Keith Morgan
Domain: kmorgan@atl.ge.com
Path: !mcnc!ge-rtp!atl.ge.com!kmorgan
------------------------------
Message-ID: <9002281528.aa13170@mintaka.lcs.mit.edu>
Date: Wed, 28 Feb 90 10:43 GMT
From: STCS8004%IRUCCVAX.UCC.IE@mitvma.mit.edu
To: SCHEME@mc.lcs.mit.edu
Subject: Scheme as 1st language
My thanks to everyone who responded to my request for views on using Scheme
as the first programming language. I have tried to acknowledge each
individual response but I have had several 'undeliverable mail' messages as
a result. If you did not get an acknowledgement from me direct please accept
my thanks now!
G. Oulsnam
------------------------------
Message-ID: <9002281648.AA01350@daystar.aca.mcc.com>
Date: Wed, 28 Feb 90 10:48:51 CST
From: "David D. Loeffler" <loeffler@mcc.com>
Reply-To: "David D. Loeffler" <loeffler@mcc.com>
To: eru!luth!sunic!dkuug!iesd!normark@bloom-beacon.mit.edu
CC: scheme@mc.lcs.mit.edu
Subject: A Report on Object-oriented Programming in Scheme.
I would like a copy of the report please.
Dave
------------------------------
Message-ID: <1851@skye.ed.ac.uk>
Date: 27 Feb 90 14:56:17 GMT
From: Jeff Dalton <mcsun!ukc!edcastle!aiai!jeff@uunet.uu.net>
To: scheme@MC.lcs.mit.edu
Subject: Re: A Franz Lisp question.
In article <660@shuldig.Huji.Ac.IL> misha@boojum.huji.ac.il writes:
>As you all might well know, Franz Lisp is a dynamic binding langauge, while
>Scheme is not. Therefore, the following code is unwriteable in Franz Lisp:
>
>(define (func param)
> (lambda (x) (param x)))
>
>[This function accepts a parameter which is also a function, and returns yet
>another function which 'apply's param on x.]
In Opus 38.92, you would write this:
(declare (special param))
(defun func (param)
(fclosure '(param)
#'(lambda (x) (funcall param x))))
"funcall" is used to call a functional object. "fclosure" is
used to make a closure over dynamic (ie, special) variables.
Hence "param" must be declared special if you want your code
to compile correctly.
The problem with compilation occurs because Franz is not a totally
dynamic binding language. It is for interpreted code, but in compiled
code variables have lexical scope (but only dynamic extent) by default.
-- Jeff
------------------------------
Message-ID: <6960@internal.Apple.COM>
Date: 28 Feb 90 18:57:58 GMT
From: Paul Snively <snorkelwacker!apple!apple.com!chewy@bloom-beacon.mit.edu>
To: scheme@MC.lcs.mit.edu
Subject: Re: problems/risks due to programming language, stories requested
In article <BILL.90Feb27143004@hcx2.ssd.harris.com> bill@ssd.harris.com
(Bill Leonard) writes:
> In article <9790@medusa.cs.purdue.edu> gb@cs.purdue.EDU (Gerald
Baumgartner) writes:
> Again it looks like this bug wouldn't have occurred in another
> programming language.
>
> I can't resist saying that this last statement seems to me to be utter
> nonsense. What programming language (read, compiler) can read the
> programmer's mind and tell what he meant? The use of the "break"
statement
> was a logic error (actually, it sounds like it was a lack of knowledge of
> the language, since "break" does not apply to "if"). I can't imagine a
> programming language that could discern this type of error. [If I use
> WHILE instead of IF, for instance, I can expect some things to work and
> some not. Yet I seriously doubt any compiler could possibly detect this
> error.]
>
> I certainly think programmers often choose an inappropriate language,
but I
> shy away from anecdotal stories like these because they seem (to me) to
> spread a lot of misinformation. Unless you implement a project in
multiple
> languages, it is nothing more than a guess to say what would have
happened
> if the project had been implemented in some other language. Perhaps you
> would have discovered an even more serious flaw in that language, or you
> might simply find it was no better or worse than the one you chose, just
> different.
>
> Most of the stories I have heard along these lines all struck me as
missing
> the point: how well was the program tested? Were there code reviews?
> Design reviews? All of these techniques are proven to reduce errors.
Most
> of the errors in these stories (e.g., the infamous dot-versus-comma one)
> should have been found with even rudimentary testing.
>
> Use of an inappropriate language is no excuse for abandoning other
techniques
> of good software engineering.
I don't think that anyone's claiming that it is an excuse; I believe the
point was that some languages applied to some tasks lend themselves to
error more than another language applied to the same task. If you wish to
interpret the above story as a rather pointed jab at the C programming
language, and object to C being treated that way, that's fine, but please
just say so.
For what it's worth, my personal opinion is that C lends itself to
precisely the kinds of errors noted above--when does break work and when
doesn't it, and why in God's name do you need it in switch statements in
the first place, etc. I believe that it's C's historical looseness that
is simultaneously its greatest weakness, when it leads to errors like
this, and its greatest strength--C doesn't restrict you; C is mean and
lean; C is close to the hardware; real programmers use C; even, God help
us, C is the only language you need! We all know C programmers whose
machismo is thus huffed and puffed up (another of my personal opinions is
that the per capita arrogance of C programmers far outweighs the per
capita arrogance of any other language-aficionado group).
Now to get back to the important point: what language would have been
better for the task in question?
Well, I hate to say it, but it's extremely unlikely that such an error
would have been made in Pascal, since Pascal doesn't require you to
explicitly break from case...of constructs.
Before the flames start, let me just add: no, I don't necessarily prefer Pascal over C for all tasks. I generally attempt to choose the right tool for the job, rather than falling into the "when all you have is a hammer, everything looks like a nail" trap.
Standard Disclaimer.
------------------------------
Message-ID: <1990Feb28.213543.21748@sun.soe.clarkson.edu>
Date: 28 Feb 90 21:35:43 GMT
From: Jason Coughlin <bu.edu!snorkelwacker!usc!zaphod.mps.ohio-state.edu!rpi!image.soe.clarkson.edu!jk0@bloom-beacon.mit.edu>
To: scheme@MC.lcs.mit.edu
Subject: Re: problems/risks due to programming language, stories requested
From article <6960@internal.Apple.COM>, by chewy@apple.com (Paul Snively):
> For what it's worth, my personal opinion is that C lends itself to
> precisely the kinds of errors noted above--when does break work and when
> doesn't it, and why in God's name do you need it in switch statements in
> the first place, etc.
Gee, if you read the language defn you'd know exactly when break
applies and when break doesn't. It seems to me that it is the
programmer's responsibility to know the language in which he is going to
implement said project -- it's not necessarily the language's responsibility
to know the programmer didn't read the defn.
> Well, I hate to say it, but it's extremely unlikely that such an error
> would have been made in Pascal, since Pascal doesn't require you to
> explicitly break from case...of constructs.
And without knowing the project, you have no business making the
assertion that Pascal was better than C [especially on a Unix box] or
that C was better than Pascal [especially on a VMS box].
--
Jason Coughlin ( jk0@sun.soe.clarkson.edu , jk0@clutx )
"Every jumbled pile of person has a thinking part that wonders what the
part that isn't thinking isn't thinking of." - They Might Be Giants
------------------------------
End of Scheme Digest
********************
∂02-Mar-90 0044 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #314
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 2 Mar 90 00:44:27 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA08371; Fri, 2 Mar 90 03:37:28 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Fri, 2 Mar 90 03:36:24 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa20325;
2 Mar 90 3:04 EST
Message-Id: <DIGEST.184.900302.021851.13@MC.LCS.MIT.EDU>
Date: 2 Mar 90 02:18:51 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #314
Scheme Digest #314 2 Mar 90 02:18:51 EST
Today's Topics:
Stepper for XSCHEME Wanted
xscheme request
Need letrec
problems/risks due to programming language, stories requested (3 messages)
in defense of C (2 messages)
C callable scheme interpreter
----------------------------------------------------------------------
Message-ID: <5485@bgsuvax.UUCP>
Date: 1 Mar 90 06:59:40 GMT
From: Walter Maner <bu.edu!snorkelwacker!tut.cis.ohio-state.edu!bgsuvax!maner@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Stepper for XSCHEME Wanted
There exists an excellent single-stepper for XLISP. Does similar software
exist for XSCHEME?
--
InterNet maner@andy.bgsu.edu (129.1.1.2) | BGSU, Comp Science Dept
UUCP ... ! osu-cis ! bgsuvax ! maner | Bowling Green, OH 43403
BITNet MANER@BGSUOPIE | 419/372-2337 Secretary
Relays @relay.cs.net, @nsfnet-relay.ac.uk | FAX is available - call
------------------------------
Message-ID: <2556@cs-spool.calgary.UUCP>
Date: 28 Feb 90 15:31:01 GMT
From: William Mcneill <van-bc!ubc-cs!alberta!calgary!cpsc!mcneill@ucbvax.berkeley.edu>
To: scheme@mc.lcs.mit.edu
Subject: xscheme request
Could someone please inform me as to where I can get a copy of the
source for the latest version of xscheme. I beleive that xscheme is
now up to version 2.2? Please note that I do not have ftp access from
this site.
Thanks in Advance
Blake McNeill
------------------------------
Message-ID: <7900001@ux1.cso.uiuc.edu>
Date: 1 Mar 90 17:39:51 GMT
From: zaphod.mps.ohio-state.edu!uwm.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!cs325ec@think.com
To: scheme@mc.lcs.mit.edu
Subject: Need letrec
If anyone has some time, could you take the time to mail
me a letrec funtion definition (or macro) that will work
on the simplest of scheme implementations... i.e. only
+,- etc., null? car, cons etc.
Thanks
-Greg
------------------------------
Message-ID: <34416@news.Think.COM>
Date: 1 Mar 90 19:00:10 GMT
From: Barry Margolin <barmar@think.com>
To: scheme@mc.lcs.mit.edu
Subject: Re: problems/risks due to programming language, stories requested
In article <1990Feb28.213543.21748@sun.soe.clarkson.edu> jk0@image.soe.clarkson.edu (Jason Coughlin) writes:
> Gee, if you read the language defn you'd know exactly when break
>applies and when break doesn't. It seems to me that it is the
>programmer's responsibility to know the language in which he is going to
>implement said project -- it's not necessarily the language's responsibility
>to know the programmer didn't read the defn.
What would you say if a car designer used a similar excuse: Gee, if you'd
read the owner's manual for the 6000SUX you'd know that you have to turn
the radio off before stepping on the brake pedal. It seems to me that it
is the driver's responsibility to know the car he's driving -- it's not
necessarily the manufacturer's responsibility to know that the driver
didn't read the manual.
Yes, it's the resposibility of the programmer to know the language. But
it's the responsibility of language designers to design languages
reasonably. If programmer-friendliness weren't an issue we'd still be
programming in machine language.
--
Barry Margolin, Thinking Machines Corp.
barmar@think.com
{uunet,harvard}!think!barmar
------------------------------
Message-ID: <1883@skye.ed.ac.uk>
Date: 1 Mar 90 15:33:23 GMT
From: Jeff Dalton <mcsun!ukc!edcastle!aiai!jeff@uunet.uu.net>
To: scheme@mc.lcs.mit.edu
Subject: Re: problems/risks due to programming language, stories requested
In article <6960@internal.Apple.COM> chewy@apple.com (Paul Snively) writes:
>machismo is thus huffed and puffed up (another of my personal opinions is
>that the per capita arrogance of C programmers far outweighs the per
>capita arrogance of any other language-aficionado group).
Except for Pascal programmers. Even Wirth has moved on by now.
------------------------------
Message-ID: <9003012059.AA11786@schizo.samsung.com>
Date: Thu, 1 Mar 90 15:35:23 EDT
From: gjc@mitech.com
Reply-To: gjc@mitech.com
To: scheme@mc.lcs.mit.edu
Subject: in defense of C
In defense of C?
(Or an apology for small extensible languages with minimal overhead
and minimal required runtime libraries).
The key here is the phrase "equivalent program in Pascal" coupled
with the extremely important suggestion I made, which is that C
could be used like you use lisp.
You say C has no array bounds checking. (In a way, big deal,
certainly the Lispmachines had extremely good low-level checking
of that nature, but it didn't keep the software or user from
being able to "... let machines crash or behave strangely" as Steele puts it).
It is so easy to build up error-checking routines from
non-error-checking primitives. Is that not what we do in lisp? (Maybe
we only *used* to do it, a lost art?) Here are some declarations from
some code I use every day:
struct bitarray
{long width; long height; char *data;};
int bitaref(struct bitarray *,int,int);
void bitaset(struct bitarray *,int,int,int);
struct bitarray *cons_bitarray(long,long);
Now, with prototype-enforcement there is absolutely no way my program is
going to crash or behave badly if I use these three guys, cons_bitarray,
bitaref and bitaset.
The prototype-enforcement makes sure I'm not calling these on data
that are not bit arrays and integers. My C-compiler can inline these
and remove redundant error checking in many case.
I claim: A good engineer can generate a much richer and more useful set of
subroutines of this nature than found in ANY LANGUAGE DESIGNED BY COMMITTEE.
.. especially compared to those those languages who's references manuals
start overflowing into multiple volumes!
On the subject of I/O primitives. "Gets" is one of those line-at-a-time
(what I called mainframe-style) procedures. Not what I had in mind (also,
not really what you should be calling primitive). Better to think in terms
of getc and putc, or read and write, or XGetNextEvent.
-gjc
p.s. "... let machines crash or behave strangely", personally *no* I
don't use the Macintosh and try to avoid writing Unix kernel code.
------------------------------
Message-ID: <39109@apple.Apple.COM>
Date: 1 Mar 90 21:42:21 GMT
From: Chuck Lins <bu.edu!snorkelwacker!apple!lins@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: problems/risks due to programming language, stories requested
In article <1883@skye.ed.ac.uk> jeff@aiai.UUCP (Jeff Dalton) writes:
>In article <6960@internal.Apple.COM> chewy@apple.com (Paul Snively) writes:
> >machismo is thus huffed and puffed up (another of my personal opinions is
> >that the per capita arrogance of C programmers far outweighs the per
> >capita arrogance of any other language-aficionado group).
>
>Except for Pascal programmers. Even Wirth has moved on by now.
↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑
Yup. Even beyond Modula-2 to Oberon. And several colleagues at ETHZ have
enhance Oberon with object-oriented extensions.
--
Chuck Lins | "Exit left to funway."
Apple Computer, Inc. | Internet: lins@apple.com
20525 Mariani Avenue | AppleLink: LINS
Mail Stop 41-K |
Cupertino, CA 95014 | "Self-proclaimed Object Oberon Evangelist"
The intersection of Apple's ideas and my ideas yields the empty set.
------------------------------
Message-ID: <5799@udccvax1.acs.udel.EDU>
Date: 1 Mar 90 22:50:35 GMT
From: John D Mccalpin <mccalpin@vax1.acs.udel.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: in defense of C
In article <9003012059.AA11786@schizo.samsung.com> gjc@mitech.com writes:
>In defense of C?
>(Or an apology for small extensible languages with minimal overhead
> and minimal required runtime libraries).
>It is so easy to build up error-checking routines from
>non-error-checking primitives.
>Here are some declarations from some code I use every day:
[...example deleted...]
>Now, with prototype-enforcement there is absolutely no way my program is
>going to crash or behave badly if I use these three guys, cons_bitarray,
>bitaref and bitaset.
Maybe a step farther is the TYPES package by Saul Youssef at Florida
State which provides an object-oriented programming environment within
a FORTRAN implementation. By making careful use of arrays pretending
to be structures, it is possible to write fairly robust code even though
the language semantics provide very little protection on type-checking
on such. The TYPES package provides queues, ordered sets, lists, etc.,
all accessible and operated on by FORTRAN subroutines.
Inquiries to youssef@scri1.scri.fsu.edu
>I claim: A good engineer can generate a much richer and more useful set of
>subroutines of this nature than found in ANY LANGUAGE DESIGNED BY COMMITTEE.
But should every engineer *have*to* generate all of those subroutines?
Certainly it is possible to write your own error-checking code and
such, but many of us were hired to get work done, not to individually
re-created safe programming languages/environments.
>... especially compared to those those languages who's references manuals
>start overflowing into multiple volumes! -gjc
But it is certainly possible to write a fairly simple language which
provides a good degree of reliability and which does not allow many
of the most common forms of errors that C and FORTRAN are full of.
A good example is Turing-Plus, which combines a fairly restrictive
and safe language with the ability to do all those nasty things that
C and FORTRAN programmers love so.... You just have be be very specific
about telling the machine that you are doing something tricky.
Ditto for Modula-3, as far as I can tell. (I have not yet gotten
it operational on my SparcStation.)
Not all strongly-typed and checked languages need to be Ada....
--
John D. McCalpin - mccalpin@vax1.acs.udel.edu
mccalpin@delocn.udel.edu
mccalpin@scri1.scri.fsu.edu
------------------------------
Message-ID: <9003020249.AA10901@LUBEC.MIT.EDU>
Date: Thu, 1 Mar 90 21:49:50 -0500
From: mory@athena.mit.edu
To: scheme@mc.lcs.mit.edu
CC: mory@athena.mit.edu, lasdev@athena.mit.edu
Subject: C callable scheme interpreter
I would like a public domain c callable scheme interpreter for use as
an extension language. Any recommendations?
Mory
------------------------------
End of Scheme Digest
********************
∂03-Mar-90 0005 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #315
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 3 Mar 90 00:05:49 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA26935; Sat, 3 Mar 90 03:00:22 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Sat, 3 Mar 90 02:59:25 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22726;
3 Mar 90 2:38 EST
Message-Id: <DIGEST.184.900303.020358.18@MC.LCS.MIT.EDU>
Date: 3 Mar 90 02:03:57 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #315
Scheme Digest #315 3 Mar 90 02:03:57 EST
Today's Topics:
in defense of C (2 messages)
problems/risks due to programming language, stories requested (5 messages)
problems/risks due to programming language
----------------------------------------------------------------------
Message-ID: <9003021617.AA16492@zurich.ai.mit.edu>
Date: Fri, 2 Mar 90 11:17:09 est
From: Franklyn Turbak <lyn@zurich.ai.mit.edu>
To: Scheme@lcs.mit.edu
Subject: Re: in defense of C
In article <5799@udccvax1.acs.udel.EDU>, mccalpin@vax1.acs.udel.edu writes:
> >I claim: A good engineer can generate a much richer and more useful set of
> >subroutines of this nature than found in ANY LANGUAGE DESIGNED BY COMMITTEE.
>
> But should every engineer *have*to* generate all of those subroutines?
> Certainly it is possible to write your own error-checking code and
> such, but many of us were hired to get work done, not to individually
> re-created safe programming languages/environments.
Indeed, the expressiveness of a language depends not only on what the
language allows you to say but also on what it doesn't force you to
say. Given any language with reasonable enough abstraction facilities
(chiefly procedures and macros) it is *possible* to write clean and
safe code, but not necessarily *easy* to do so.
The hallmark of a language is the extent to which it abstracts over
common programming patterns. If Scheme didn't support SET! or
CALL-WITH-CURRENT-CONTINUATION it would be possible to simulate them
by passing an explicit store and continuation to every procedure (in
the denotational semantics "style"), but programs would become
cumbersome to write and impenetrable to read. SET! and
CALL-WITH-CURRENT-CONTINUATION are useful language features exactly
because they embed into the language patterns which otherwise would
have to created again and again by hand.
A similar argument can be made for a variety of other language
features: types, data abstraction facilities, error-handling
facilities, etc. Sure, it's always possible to simulate these in some
explicit fashion; but do we want to *have* to?
- Lyn -
------------------------------
Message-ID: <1004@micropen>
Date: 2 Mar 90 19:19:01 GMT
From: "David F. Carlson" <zaphod.mps.ohio-state.edu!sunybcs!uhura.cc.rochester.edu!ur-valhalla!micropen!dave@think.com>
To: scheme@MC.lcs.mit.edu
Subject: Re: problems/risks due to programming language, stories requested
In article <6960@internal.Apple.COM>, chewy@apple.com (Paul Snively) writes:
>
>
> For what it's worth, my personal opinion is that C lends itself to
> precisely the kinds of errors noted above--when does break work and when
> doesn't it, and why in God's name do you need it in switch statements in
> the first place, etc.
What break does is *very* well defined and is no more prone to misinterpretation
that any other non-linear control flow statement in any other PL.
From K&R2 p 244:
A9.5: iteration statement is (for, while, do)...
A break statement may appear only in an iteration statement or a switch
statement; control passes to the statement following the terminated
statement.
A multi-case switch is very handy in many situations to reduce identical
treatments for similar cases. That you ask the question of the usefulness
of break-per-case/multiple-cases implies that you haven't sufficient experience
with the construct to judge its merits/weaknesses.
Dijkstra notes that no programming language can prevent a poor programmer from
creating bad programs.
--
David F. Carlson, Micropen, Inc.
micropen!dave@ee.rochester.edu
"The faster I go, the behinder I get." --Lewis Carroll
------------------------------
Message-ID: <8218@hubcap.clemson.edu>
Date: 2 Mar 90 22:15:22 GMT
From: "William Thomas Wolfe, 2847 " <zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!hubcap!billwolf%hazel.cs.clemson.edu@think.com>
To: scheme@mc.lcs.mit.edu
Subject: Re: problems/risks due to programming language, stories requested
From dave@micropen (David F. Carlson):
>> For what it's worth, my personal opinion is that C lends itself to
>> precisely the kinds of errors noted above--when does break work and when
>> doesn't it, and why in God's name do you need it in switch statements in
>> the first place, etc.
>
> A multi-case switch is very handy in many situations to reduce identical
> treatments for similar cases.
So is a multi-alternative case, as provided by Ada:
case Foo is
when 1 | 3 | 5 =>
statement1;
when 2 | 4 | 6 =>
statement2;
when others =>
statement3;
end case;
The difference is that Ada takes care of exiting the case statement
for you, whereas C requires (unsafely) that you use a break to avoid
being sucked into the code associated with subsequent cases.
Bill Wolfe, wtwolfe@hubcap.clemson.edu
------------------------------
Message-ID: <9897@medusa.cs.purdue.edu>
Date: 2 Mar 90 23:01:08 GMT
From: "William J. Bouma" <bouma@purdue.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: problems/risks due to programming language, stories requested
In article <6960@internal.Apple.COM> chewy@apple.com (Paul Snively) writes:
>We all know C programmers whose
>machismo is thus huffed and puffed up (another of my personal opinions is
>that the per capita arrogance of C programmers far outweighs the per
>capita arrogance of any other language-aficionado group).
Oh, really! I can tell you have never met any FORTH programmers.
>Well, I hate to say it, but it's extremely unlikely that such an error
>would have been made in Pascal, since Pascal doesn't require you to
>explicitly break from case...of constructs.
Well isn't that special! The way I see it, C gives you the flexibility
to not break if you don't want to, where PASCAL restricts you to break.
>Before the flames start,
Too late!
> let me just add: no, I don't necessarily prefer Pascal over C for all tasks.
The only place I can see to prefer PASCAL over C is a beginner programming
class. Isn't PASCAL usually thrown out along with the diapers?
--
Bill <bouma@cs.purdue.edu> | And don't forget my dog... "Astronomy" -- BOC
------------------------------
Message-ID: <14258@lambda.UUCP>
Date: 2 Mar 90 23:27:22 GMT
From: Jim Giles <lambda!jlg@lanl.gov>
To: scheme@mc.lcs.mit.edu
Subject: Re: problems/risks due to programming language, stories requested
From article <1004@micropen>, by dave@micropen (David F. Carlson):
> [... explicit breaks in the C switch construct ...]
> Dijkstra notes that no programming language can prevent a poor programmer from
> creating bad programs.
He also notes that the choice of programming language can have a strong
effect on the quality of the resulting code. (His indictment of PL/I
as being similar to flying a widebodied jet with all the windows taped
over and no labels on the thousands of controls was quite apropos.)
This effect of the language choice is mainly psychological - and it
CAN be overcome (which is the main thrust of many of Dijkstra's works).
But, be honest, how many programmers do you know who _really_ construct
their programs abstractly _before_ even selecting their implementation
language? This is the proper way (a' la Dijkstra) to make sure the
you aren't negatively impacted by the language - you select the proper
language for the job at hand - you don't mangle the job to fit the
language.
Dijkstra's statement, while true, should not be used to excuse poorly
designed language features (as you are trying to do). A better design
for C would have been _not_ to require breaks after each case and to
provide some other syntax for the representation of multiple choices
on the same case. It's easy to see these kinds of design errors
in retrospect (C _is_ nearly 20 years old you know).
J. Giles
------------------------------
Message-ID: <6984@ubc-cs.UUCP>
Date: 3 Mar 90 02:23:33 GMT
From: Vincent Manis <van-bc!ubc-cs!manis@uunet.uu.net>
To: scheme@mc.lcs.mit.edu
Subject: Re: problems/risks due to programming language, stories requested
I might note that B's syntax, and hence C's syntax, was a definite
*dis*improvement [sic] over that of its predecessor, BCPL. I would in
fact post an article saying exactly that, except for the fact that this
entire thread most certainly belongs somewhere, but not in
comp.lang.scheme. Would you please edit the Newsgroups: line in further
articles on this subject?
--
\ Vincent Manis <manis@cs.ubc.ca> "There is no law that vulgarity and
\ Department of Computer Science literary excellence cannot coexist."
/\ University of British Columbia -- A. Trevor Hodge
/ \ Vancouver, BC, Canada V6T 1W5 (604) 228-2394
------------------------------
Message-ID: <16078@haddock.ima.isc.com>
Date: 3 Mar 90 02:10:47 GMT
From: Karl Heuer <snorkelwacker!spdcc!ima!haddock!karl@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: problems/risks due to programming language
In article <1004@micropen> dave@micropen (David F. Carlson) writes:
>What break does is *very* well defined and is no more prone to
>misinterpretation that any other non-linear control flow statement ...
Yes, it's well defined, but what it's defined to do is bad.
For a formal treatment of the above statement, I refer you to my article
<16039@haddock.ima.isc.com>, posted to comp.lang.misc (also .c and .ada) with
this same title. I haven't seen any rebuttals yet.
>A multi-case switch is very handy in many situations ...
Yeah. I wish C had this feature, instead of simulating it with fallthrough.
>That you ask the question of the usefulness of break-per-case/multiple-cases
>implies that you haven't sufficient experience with the construct to judge
>its merits/weaknesses.
I don't know about the person you were addressing, but I think I've had
sufficient experience with it. I certainly question its usefulness in
comparison to something reasonable, like the language I described in my other
article.
In fact, even if you insist that the comparison must be between C and
plain-C-without-break-switch, I think I'd still go for the latter. I believe
the benefit of not requiring an overloaded keyword to do a break-switch
exceeds the cost of having to use a goto to merge related cases.
Karl W. Z. Heuer (karl@ima.ima.isc.com or harvard!ima!karl), The Walking Lint
------------------------------
Message-ID: <1903@skye.ed.ac.uk>
Date: 2 Mar 90 14:59:35 GMT
From: Jeff Dalton <mcsun!ukc!edcastle!aiai!jeff@uunet.uu.net>
To: scheme@mc.lcs.mit.edu
Subject: Re: in defense of C
In article <9003012059.AA11786@schizo.samsung.com> gjc@mitech.com writes:
>The key here is the phrase "equivalent program in Pascal" coupled
>with the extremely important suggestion I made, which is that C
>could be used like you use lisp.
Not only that, who says C can't have array bounds checking. As far
as I can tell, the lack of them is just an implementation tradition.
Pointers would have to be more complex, but fi you want bounds
checking enough you'd presumably be willing to pay.
Besides, since when does Lisp make such checks. Sure, most Lisps
probably check array bounds, but most do not check whether CAR and
CDR are really being applied to conses (just for example).
As GJC notes, Lisp programmers have developed ways to deal with
this, as have C programmers.
>You say C has no array bounds checking. (In a way, big deal,
>certainly the Lispmachines had extremely good low-level checking
>of that nature, but it didn't keep the software or user from
>being able to "... let machines crash or behave strangely" as Steele puts it).
That too.
------------------------------
End of Scheme Digest
********************
∂04-Mar-90 0100 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #316
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 4 Mar 90 01:00:28 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA06688; Sun, 4 Mar 90 03:56:37 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Sun, 4 Mar 90 03:55:40 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa16313;
4 Mar 90 3:37 EST
Message-Id: <DIGEST.184.900304.030359.23@MC.LCS.MIT.EDU>
Date: 4 Mar 90 03:03:59 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #316
Scheme Digest #316 4 Mar 90 03:03:59 EST
Today's Topics:
subscribe
problems/risks due to programming language, stories requested (2 messages)
xscheme request
----------------------------------------------------------------------
Message-ID: <9003030421.aa26521@mintaka.lcs.mit.edu>
Date: Sat, 3 Mar 90 17:19 H
From: WONGWF%NUSDISCS.BITNET@mitvma.mit.edu
To: scheme@mc.lcs.mit.edu
Subject: subscribe
wongwf@nusdiscs.bitnet
------------------------------
Message-ID: <707179.900303.ALAN@AI.AI.MIT.EDU>
Date: Sat, 3 Mar 90 22:24:10 EST
From: Alan Bawden <ALAN%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU>
To: Scheme@MC.LCS.MIT.EDU
Subject: problems/risks due to programming language, stories requested
Date: 2 Mar 90 19:19:01 GMT
From: David F. Carlson
... What break does is *very* well defined
Of course there is more to designing a good programming language than
making sure that it is "well defined".
and is no more prone to misinterpretation that any other non-linear
control flow statement in any other PL....
I beg to differ. You would be much less likely to make the kind of error
that started this discussion if you could give -names- to switch, while, do
and for statements, and if break and continue allowed you to name the
particular statement that was to be broken or continued.
Common Lisp has the RETURN-FROM special form because we learned this lesson
from the original MacLisp RETURN special form.
------------------------------
Message-ID: <2556@cs-spool.calgary.UUCP>
Date: 28 Feb 90 15:31:01 GMT
From: William Mcneill <van-bc!ubc-cs!alberta!calgary!cpsc!mcneill@ucbvax.berkeley.edu>
To: scheme@mc.lcs.mit.edu
Subject: xscheme request
Could someone please inform me as to where I can get a copy of the
source for the latest version of xscheme. I beleive that xscheme is
now up to version 2.2? Please note that I do not have ftp access from
this site.
Thanks in Advance
Blake McNeill
------------------------------
Message-ID: <1883@skye.ed.ac.uk>
Date: 1 Mar 90 15:33:23 GMT
From: Jeff Dalton <eru!luth!sunic!mcsun!ukc!edcastle!aiai!jeff@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: problems/risks due to programming language, stories requested
In article <6960@internal.Apple.COM> chewy@apple.com (Paul Snively) writes:
>machismo is thus huffed and puffed up (another of my personal opinions is
>that the per capita arrogance of C programmers far outweighs the per
>capita arrogance of any other language-aficionado group).
Except for Pascal programmers. Even Wirth has moved on by now.
------------------------------
End of Scheme Digest
********************
∂05-Mar-90 0058 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #317
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 5 Mar 90 00:58:22 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA17493; Mon, 5 Mar 90 03:56:30 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Mon, 5 Mar 90 03:55:34 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa08099;
5 Mar 90 3:22 EST
Message-Id: <DIGEST.184.900305.024908.27@MC.LCS.MIT.EDU>
Date: 5 Mar 90 02:49:07 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #317
Scheme Digest #317 5 Mar 90 02:49:07 EST
Today's Topics:
in defense of C
----------------------------------------------------------------------
Message-ID: <1903@skye.ed.ac.uk>
Date: 2 Mar 90 14:59:35 GMT
From: Jeff Dalton <eru!luth!sunic!mcsun!ukc!edcastle!aiai!jeff@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: in defense of C
In article <9003012059.AA11786@schizo.samsung.com> gjc@mitech.com writes:
>The key here is the phrase "equivalent program in Pascal" coupled
>with the extremely important suggestion I made, which is that C
>could be used like you use lisp.
Not only that, who says C can't have array bounds checking. As far
as I can tell, the lack of them is just an implementation tradition.
Pointers would have to be more complex, but fi you want bounds
checking enough you'd presumably be willing to pay.
Besides, since when does Lisp make such checks. Sure, most Lisps
probably check array bounds, but most do not check whether CAR and
CDR are really being applied to conses (just for example).
As GJC notes, Lisp programmers have developed ways to deal with
this, as have C programmers.
>You say C has no array bounds checking. (In a way, big deal,
>certainly the Lispmachines had extremely good low-level checking
>of that nature, but it didn't keep the software or user from
>being able to "... let machines crash or behave strangely" as Steele puts it).
That too.
------------------------------
End of Scheme Digest
********************
∂06-Mar-90 0038 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #318
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 6 Mar 90 00:37:57 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA06780; Tue, 6 Mar 90 03:33:10 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Tue, 6 Mar 90 03:32:20 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa09367;
6 Mar 90 3:07 EST
Message-Id: <DIGEST.184.900306.023411.33@MC.LCS.MIT.EDU>
Date: 6 Mar 90 02:34:11 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #318
Scheme Digest #318 6 Mar 90 02:34:11 EST
Today's Topics:
in defense of C
TeX Manual for xscheme?
----------------------------------------------------------------------
Message-ID: <14112@cbnewsc.ATT.COM>
Date: 5 Mar 90 15:19:48 GMT
From: "lawrence.g.mayka" <att!cbnewsc!lgm@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: in defense of C
[I have added comp.lang.lisp to the newsgroup list.]
In article <1903@skye.ed.ac.uk> jeff@aiai.UUCP (Jeff Dalton) writes:
>Besides, since when does Lisp make such checks. Sure, most Lisps
>probably check array bounds, but most do not check whether CAR and
>CDR are really being applied to conses (just for example).
On Lisp-directed processor architectures, dynamic type checks are
(typically) uniformly applied, often in parallel with the
computation of the most-common-case result. On conventional (C-
and Fortran-directed) architectures, Common Lisp vendors typically
offer a range of safety/efficiency tradeoffs. One can then choose
a tradeoff according to the needs, or the stage of development, of
one's application.
One of the most important quality measures of a Common Lisp
compiler is the level of safety it supports without an undue
sacrifice in execution speed. The better CL implementations score
quite highly on this scale, especially on newer processor
architectures such as SPARC. For example, the better compilers
indeed ensure that CAR and CDR are only applied to lists, without
a loss of execution speed and even though a CL implementation must
permit one to apply CAR and CDR to the symbol NIL.
>As GJC notes, Lisp programmers have developed ways to deal with
>this, as have C programmers.
I venture to say that generally, Common Lisp programmers compile
unsafe code only when they have to (e.g., when the absolute
maximum execution speed is called for, or when forced by
circumstances to use an inferior CL compiler), not because they
like it. Unsafe code is not an integral part of the culture or a
badge of pride as, one might say, it seems to be for C.
Lawrence G. Mayka
AT&T Bell Laboratories
lgm@ihlpf.att.com
Standard disclaimer.
------------------------------
Message-ID: <17812@boulder.Colorado.EDU>
Date: 6 Mar 90 03:37:30 GMT
From: Dirk Grunwald <grunwald@boulder.colorado.edu>
To: scheme@MC.lcs.mit.edu
Subject: TeX Manual for xscheme?
Does anyone have the xscheme manual converted to TeX or TeXinfo format?
I want to smash it down to something other than 40 pages.
Please mail me or tell me where I can FTP it.
thanx
------------------------------
End of Scheme Digest
********************
∂06-Mar-90 2357 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #319
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 6 Mar 90 23:57:02 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA25684; Wed, 7 Mar 90 02:56:00 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Wed, 7 Mar 90 02:54:57 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa07350;
7 Mar 90 2:43 EST
Message-Id: <DIGEST.184.900307.021914.39@MC.LCS.MIT.EDU>
Date: 7 Mar 90 02:19:14 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #319
Scheme Digest #319 7 Mar 90 02:19:14 EST
Today's Topics:
IEEE CS membership cost (correction)
----------------------------------------------------------------------
Message-ID: <9003060844.aa02089@mintaka.lcs.mit.edu>
Date: Tue, 6 Mar 90 08:44:23 -0500
From: Chris Haynes <chaynes@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu, scheme-standard@wheaties.ai.mit.edu,
scheme@mc.lcs.mit.edu
Subject: IEEE CS membership cost (correction)
In a previous note on balloting for the draft IEEE Scheme standard, I
stated that ACM members could join the IEEE Computer Society for $13.
I was misinformed. The cost for 6 months of Computer Society
membership is $23.50. They don't take 12 month membership
applications at this time of year, and ACM members only get a break if
they join the IEEE proper, which is considerably more expensive.
Once more, you should be an IEEE or Computer Society member if you
wish to ballot on the Scheme standard.
-- Chris Haynes
------------------------------
End of Scheme Digest
********************
∂08-Mar-90 0253 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #320
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 8 Mar 90 02:53:28 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA17222; Thu, 8 Mar 90 05:53:25 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Thu, 8 Mar 90 05:52:28 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa06728;
8 Mar 90 5:50 EST
Message-Id: <DIGEST.184.900308.054917.45@MC.LCS.MIT.EDU>
Date: 8 Mar 90 05:49:17 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #320
Scheme Digest #320 8 Mar 90 05:49:17 EST
Today's Topics:
in defense of C
----------------------------------------------------------------------
Message-ID: <1942@skye.ed.ac.uk>
Date: 6 Mar 90 19:36:27 GMT
From: Jeff Dalton <mcsun!ukc!edcastle!aiai!jeff@uunet.uu.net>
To: scheme@mc.lcs.mit.edu
Subject: Re: in defense of C
In article <14112@cbnewsc.ATT.COM> lgm@cbnewsc.ATT.COM (lawrence.g.mayka,ihp,) writes:
>One of the most important quality measures of a Common Lisp
>compiler is the level of safety it supports without an undue
>sacrifice in execution speed. The better CL implementations score
>quite highly on this scale, especially on newer processor
>architectures such as SPARC. For example, the better compilers
>indeed ensure that CAR and CDR are only applied to lists, without
>a loss of execution speed and even though a CL implementation must
>permit one to apply CAR and CDR to the symbol NIL.
You say this as if it were typical of better compilers on machines
other than SPARCs, such as, maybe, 68020s. Can they really have safe
CARs and CDRs, without loss of speed, on a 68020? If so, I would
expect that safety to remain even if I set saftey=0, but that doesn't
seem to be what happens. Moreover, how many of the SPARC compilers
can do this? I suspect it's only one or two of them.
-- Jeff
------------------------------
End of Scheme Digest
********************
∂09-Mar-90 0010 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #321
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 9 Mar 90 00:10:06 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA05994; Fri, 9 Mar 90 03:08:05 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Fri, 9 Mar 90 03:06:59 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa16519;
9 Mar 90 2:41 EST
Message-Id: <DIGEST.184.900309.020030.50@MC.LCS.MIT.EDU>
Date: 9 Mar 90 02:00:30 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #321
Scheme Digest #321 9 Mar 90 02:00:30 EST
Today's Topics:
(atom? '()) => #t (2 messages)
IEEE CS membership cost (correction)
Looking for Lisp techniques and tools
constants in Scheme
call/cc
----------------------------------------------------------------------
Message-ID: <1990Mar7.194937.1421@sun.soe.clarkson.edu>
Date: 7 Mar 90 19:49:37 GMT
From: Jason Coughlin <image.soe.clarkson.edu!jk0@uunet.uu.net>
To: scheme@mc.lcs.mit.edu
Subject: (atom? '()) => #t
This one just burnt me, *badly*.
Can someone explain the rationale behind treating '() as an atom? It
seems to me that it should be a pair: it's the empty *list* not the
empty *atom*.
Given this defn of a cons node:
struct C_node {
struct CONS_NODE *car;
struct CONS_NODE *cdr;
} ;
struct CONS_NODE {
int type;
union {
struct C_node cdata;
int idata;
double fdata;
...etc..
} data;
} ;
#define CC 1 /* car is a PAIR, cdr is a pair */
#define CA 2 /* car is a PAIR, cdr is an atom */
#define AC 3 /* car is an ATOM, cdr is PAIR */
#define AA 4 /* car is an ATOM, cdr is an ATOM */
#define INT 5
#define FLOAT 6 ...etc...
(note: the C means CONS, probably should be a P for PAIR)
seem to me, that the list (a b c) should be this:
AC -> AC -> AC -> NIL
a b c
but since '() is an atom, it is in actuality this:
AC -> AC -> A A
a b c NIL
--
Jason Coughlin ( jk0@sun.soe.clarkson.edu , jk0@clutx )
"Every jumbled pile of person has a thinking part that wonders what the
part that isn't thinking isn't thinking of." - They Might Be Giants
------------------------------
Message-ID: <9894@portia.Stanford.EDU>
Date: 8 Mar 90 00:30:49 GMT
From: Rich Alderson <shelby!portia!Jessica.Stanford.Edu@decwrl.dec.com>
To: scheme@MC.lcs.mit.edu
Subject: Re: IEEE CS membership cost (correction)
In article <9003060844.aa02089@mintaka.lcs.mit.edu>, chaynes@IUVAX (Chris Haynes) writes:
>In a previous note on balloting for the draft IEEE Scheme standard, I
>stated that ACM members could join the IEEE Computer Society for $13.
>I was misinformed. The cost for 6 months of Computer Society
>membership is $23.50. They don't take 12 month membership
>applications at this time of year, and ACM members only get a break if
>they join the IEEE proper, which is considerably more expensive.
>Once more, you should be an IEEE or Computer Society member if you
>wish to ballot on the Scheme standard.
I have been an ACM member for years. Recently, when I joined the IEEE Computer
Society, I got a $5.00 break because I was a member of the ACM. I didn't have
to join the IEEE itself.
Hey, $5.00 is $5.00!
Rich Alderson
alderson@jessica.stanford.edu
------------------------------
Message-ID: <1990Mar6.152855.7731@antel.uucp>
Date: 6 Mar 90 15:28:55 GMT
From: Michael Borza <zaphod.mps.ohio-state.edu!usc!cs.utexas.edu!jarvis.csri.toronto.edu!helios.physics.utoronto.ca!ists!yunexus!maccs!antel!mike@think.com>
To: scheme@MC.lcs.mit.edu
Subject: Looking for Lisp techniques and tools
Sorry to interject Lisp/Scheme questions into this otherwise well-placed
discussion on C/Pascal/Ada/... but...
In article <9003020249.AA10901@LUBEC.MIT.EDU> mory@ATHENA.MIT.EDU writes:
>
>I would like a public domain c callable scheme interpreter for use as
>an extension language. Any recommendations?
>
> Mory
I'm just embarking on a similar trek. I've got a substantial amount of
experience with other programming languages, but I'm starting into Lisp
as a serious undertaking for the first time. I've got some specific
questions and some general ones; I'll start with the general ones so
people uninterested in the specifics can bail out early. I'm interested
to hear what tools and techniques people use for Lisp program development.
Post if you believe it's of general interest, e-mail to me will garner a
summary to the net (names will not be included in the summary).
Most of these questions probably seem simplistic; please let me know if
they are inappropriate to the level of these groups. My purpose is to
find out about what people who've done substantial program development
in Lisp use for tools and methods.
At this point, I've got Elk 1.0 up and running (pretty much), so these
questions are slanted towards Elk and Scheme; however, it's not too late
to change my mind about choice of tools, so feel free to make any
suggestions you like. PD or freely-distributed tools are preferred, but
descriptions about any tools and/or systems will be appreciated.
1. What types of tools are available for Lisp program and project
development? Presumably there are Lisp-callable editors for Lisp
programs that know about Lisp syntax. What about source-code
and project management tools? What about simple things like pagers,
directory listing tools, shell escapes, and the like? Any pointers
to where these can be found?
2. My intention is to develop an easily extended modelling language,
suitable for both interactive use for small jobs, but recognizing a
need for `batch' processing of larger ones. The processes being
simulated involve potentially huge amounts of floating-point
computation. A suitable simulation engine is already written in C.
My gut reaction is that the user interface for input to the simulator
and display of the results are probably best handled in Lisp, with a
system call invoking the simulation engine. I propose to handle the
interface between the two with intermediate files. For `batch' or
command-line driven mode, the model compiler/interpreter may optionally
need to be invoked, followed by the simulation engine; I feel that this
can be handled adequately by a suitable combination of command scripts
and possibly a C wrapper. Any comments on this approach? Does it
make more sense for the C program to invoke Lisp (which seems to be
a more commonly used technique)?
3. I've implemented a subset of the functionality I want in C, using
lex and yacc as required. I find this approach cumbersome when dealing
with an extensible language and nested layers of encapsulation. Am I
barking up the wrong tree taking a multilingual approach? What about
using Lisp in this application? It seems idealy suited to the task, but
not having tackled anything substantial in it, I may be missing something
obvious.
So end the general questions.
4. I currently have Elk 1.0 running under UNIX System V r 3.2 on an
80386. The xlib interface works, xt won't compile, but it looks like a
quick fix. The only really tricky point (for me, at least) was an apparent
change in the format of externals in COFF files between the release of
Elk and release of SysVr3.2. I still experience occassional core dumps
with segmentation violations and bus errors, esp. during autoloading and
garbage collection. At this point, I'm a little suspicious of the alloca
implementation. Before I start trying to track this down, are there any
official or unofficial patches known to fix this?
5. What's the current release level of Elk? Are there any known bugs I
should be aware of? Is it reasonable to consider increasing the amount
of memory allocated to the heap?
6. What are people's opinions of Elk? Is it in wide distribution and being
used to implement substantial projects? If not, why not? Are there more
suitable systems for the kind of project described above? Are there
Elk-specific tool kits, or Scheme tool kits known to be useful with Elk?
7. I have strived to make the existing source code for the simulation
engine portable between a number of systems, both UNIX and non-UNIX.
While not a pressing issue now, I would like to make the Lisp part of
the project similarly portable. It seems that a common approach in a
number of Lisp implementations I've seen is to provide compatibility
functions for other popular Lisp dialects. What are the issues I should
be aware of when trying to accomplish portability in Lisp, or is this
best not discussed in polite company?
That's it. Any and all responses will be greatly appreciated, especially
from you Lisp afficionados out there. If you've got other comments to
make, feel free. I'll summarize any e-mail reponses I receive in the
next, oh say, 3 weeks to the net. I promise to summarize, and I promise
not to name names.
cheers,
mike borza.
--
Michael Borza Antel Optronics Inc.
(416)335-5507 3325B Mainway, Burlington, Ont., Canada L7M 1A6
work: mike@antel.UUCP or uunet!utai!utgpu!maccs!antel!mike
home: mike@boopsy.UUCP or uunet!utai!utgpu!maccs!boopsy!mike
------------------------------
Message-ID: <7079@ubc-cs.UUCP>
Date: 8 Mar 90 03:20:13 GMT
From: Vincent Manis <van-bc!ubc-cs!manis@uunet.uu.net>
To: scheme@MC.lcs.mit.edu
Subject: Re: (atom? '()) => #t
In article <1990Mar7.194937.1421@sun.soe.clarkson.edu>
jk0@sun.soe.clarkson.edu (Jason Coughlin) writes:
>Can someone explain the rationale behind treating '() as an atom? It
>seems to me that it should be a pair: it's the empty *list* not the
>empty *atom*.
But remember, a list isn't a pair. It's zero or more pairs connected
together via a cdr chain. In fact, a pair is an object to which the car
and cdr procedures may be applied; it has been considered unkosher for
many years to allow (car '()) and (cdr '()).
--
\ Vincent Manis <manis@cs.ubc.ca> "There is no law that vulgarity and
\ Department of Computer Science literary excellence cannot coexist."
/\ University of British Columbia -- A. Trevor Hodge
/ \ Vancouver, BC, Canada V6T 1W5 (604) 228-2394
------------------------------
Message-ID: <9003081635.AA14269@tub.UUCP>
Date: Thu, 8 Mar 90 17:35:30 +0100
From: Oliver Laumann <net%TUB.BITNET@mitvma.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: constants in Scheme
I still don't quite understand which objects are considered immutable in
Scheme. The standard says "The constants and the strings returned by
symbol->string are then the immutable objects, while all objects created
by the other procedures in this Standard are mutable".
Does this mean that objects returned by, say, "read" are mutable?
Is the expression
(string-set! (read) 0 #\a))
legal, when the call to (read) returns a non-empty string? And what about
the elements of a vector constant? Is
(set-car! (vector-ref '#((a b) c) 0) 'd)
legal?
By the way, why must vector constants be quoted? Does the evaluation
of a vector constant ever return a result?
Thanks,
--
Oliver Laumann net@TUB.BITNET net@tub.cs.tu-berlin.de net@tub.UUCP
------------------------------
Message-ID: <1990Mar8.064319.28399@brutus.cs.uiuc.edu>
Date: 8 Mar 90 06:43:19 GMT
From: Aamod Sane <zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!sane@think.com>
To: scheme@mc.lcs.mit.edu
Subject: call/cc
Beginners question:
I tried to understand the operation of call/cc from Dybvigs text
and the R3.99 without success. Can someone give a good explanation here or
a reference? It is said that the interepreter uses continuations which are
not visible normally etc. but I dont quite get this.
I would also like examples/references on the Continuation
Passing style (just building of lambdas, not the call/cc variety).
I know of examples such as gcd of a list where you can escape
if a 1 is encountered without doing any computation, by building lambdas
and using them only if 1 is not found.
Thanks ,
Aamod Sane
sane@cs.uiuc.edu
------------------------------
End of Scheme Digest
********************
∂10-Mar-90 0030 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #322
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 10 Mar 90 00:30:46 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA26402; Sat, 10 Mar 90 03:28:02 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Sat, 10 Mar 90 03:27:00 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa10956;
10 Mar 90 3:13 EST
Message-Id: <DIGEST.184.900310.023445.57@MC.LCS.MIT.EDU>
Date: 10 Mar 90 02:34:44 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #322
Scheme Digest #322 10 Mar 90 02:34:44 EST
Today's Topics:
constants in Scheme
first programming languages, and second ones too
Scheme->C compiler available via FTP
problems/risks due to programming language, stories requested
(atom? '()) => #t (2 messages)
in defense of C (5 messages)
small pgms using big data?
----------------------------------------------------------------------
Message-ID: <9003090824.AA00467@zurich.ai.mit.edu>
Date: Fri, 9 Mar 90 03:24:36 est
From: Chris Hanson <cph@zurich.ai.mit.edu>
To: net%TUB.BITNET@mitvma.mit.edu
CC: scheme@mc.lcs.mit.edu
Subject: constants in Scheme
Date: Thu, 8 Mar 90 17:35:30 +0100
From: Oliver Laumann <net%TUB.BITNET@mitvma.mit.edu>
I still don't quite understand which objects are considered immutable in
Scheme. The standard says "The constants and the strings returned by
symbol->string are then the immutable objects, while all objects created
by the other procedures in this Standard are mutable".
The basic rule is that any object that appears in your program is
immutable. Thus quoted lists, quoted vectors, and any strings that
appear in the text of your program are immutable.
In addition, the strings returned by symbol->string are also
immutable.
The standard does not define any other immutable objects.
Does this mean that objects returned by, say, "read" are mutable?
Yes.
Is the expression
(string-set! (read) 0 #\a))
legal, when the call to (read) returns a non-empty string?
Yes.
And what about
the elements of a vector constant? Is
(set-car! (vector-ref '#((a b) c) 0) 'd)
legal?
This is not legal. Both the vector, and its elements (just like the
elements of a quoted list) are objects that textually appear in your
program, and thus are immutable.
By the way, why must vector constants be quoted? Does the evaluation
of a vector constant ever return a result?
Unquoted vectors are not defined as expressions; a program containing
an unquoted vector in its text is what the standard calls a
"non-conforming program". I don't know any good reason why these are
illegal.
------------------------------
Message-ID: <6914@ubc-cs.UUCP>
Date: 24 Feb 90 02:56:56 GMT
From: Vincent Manis <ubc-cs!manis@beaver.cs.washington.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: first programming languages, and second ones too
I don't want to get too far away from the purpose of this newsgroup, but
I wouldn't recommend C as an immediate successor to Scheme in a
SICP-based course. The major reasons are the convoluted syntax and the
lack of reasonable response to run-time errors. I've taught courses
using C at the second and third year levels for years, and I know for a
fact that students find both of these almost insuperable.
I am, however, in agreement with gjc that the right way to teach these
languages is by having the students work on a Scheme evaluator. That's
certainly what we had in mind.
As for going directly to assembler: in our course, we won't be using the
approach SICP uses to assembly language. We're going to introduce a
fairly conventional hypothetical machine, and then explain its behaviour
on the register transfer level. This seems more appropriate than the
SIPC one in a course which is aimed at non-electrical engineers.
--
\ Vincent Manis <manis@cs.ubc.ca> "There is no law that vulgarity and
\ Department of Computer Science literary excellence cannot coexist."
/\ University of British Columbia -- A. Trevor Hodge
/ \ Vancouver, BC, Canada V6T 1W5 (604) 228-2394
------------------------------
Message-ID: <2886@bacchus.dec.com>
Date: 23 Feb 90 23:08:29 GMT
From: Joel Bartlett <decwrl.dec.com!bartlett@decwrl.dec.com>
To: scheme@mc.lcs.mit.edu
Subject: Scheme->C compiler available via FTP
The Scheme-to-C compiler, Scheme->C, done at Digital Equipment
Corporation's Western Research Laboratory is now available for public
ftp.
The compiler compiles Revised**3 Scheme to C that is then compiled by
the native C compiler for the target machine. This design results in
a portable system that allows either stand-alone Scheme programs or
programs written in both compiled and interpreted Scheme and other
languages.
The Scheme->C system supports the essentials of Revised**3 and many
of the optionals. Extensions include "expansion passing style"
macros, a foreign function call capability, and interfaces to X11's
Xlib. The system does provide call-with-current-continuation.
Numbers are represented internally as 29-bit integers, or 64-bit
floating point values.
The compiler is written in Scheme. Most of the runtime system
(including an interpreter) is written in Scheme. The generational
compacting garbage collector and a few other things are written in C.
There is a small (< 100 lines) amount of assembly code. The system
is known to run on VAX's and DECstation 3100's running Ultrix. Other
ports should be straightforward.
The system is available for anonymous ftp from 'gatekeeper.dec.com'
[16.1.0.2]. The Scheme->C files are in '/pub/DEC/Scheme-to-C'. Those
files include:
README - overview and copyright notice.
23feb90.tar.Z - compressed tar file containing all source
and documentation.
Joel Bartlett bartlett@decwrl.dec.com
------------------------------
Message-ID: <1990Feb24.001350.2617@sq.sq.com>
Date: 24 Feb 90 00:13:50 GMT
From: Mark Brader <eru!luth!sunic!uupsi!rpi!zaphod.mps.ohio-state.edu!usc!cs.utexas.edu!jarvis.csri.toronto.edu!utgpu!utzoo!sq!msb@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: problems/risks due to programming language, stories requested
Gerald Baumgartner (gb@cs.purdue.EDU) writes in many groups:
> There is the famous story that a Mariner probe got lost
> because of the Fortran statement `DO 3 I = 1.3' (1.3 instead
> of 1,3) ... It is a nice story but, as far as I know, NASA used
> Jovial at that time and not Fortran.
Just for the record, the above was definitively shown to be fictional
according to authoritative references given in comp.risks (= Risks Digest),
issue 9.75 (I hear), not too many months ago. There is at least one
textbook that states it as truth; this is wrong. The actual reason for
the loss of Mariner I was an error in code used in recovering from a
hardware failure; the code had been based on handwritten equations, and
in transcribing one of these, an overbar was deleted from one letter.
A story which may have been the true origin of the "DO statement myth"
was posted fairly recently in alt.folklore.computers; the article
cited a program at NASA that did enter production use with a dot-for-comma
bug in a DO statement, but it wasn't a spacecraft flight control program.
(I didn't save the details and would be happy to see them again.)
Followups directed to alt.folklore.computers.
--
Mark Brader "I'm not going to post a revision: even USENET
utzoo!sq!msb, msb@sq.com readers can divide by 100." -- Brian Reid
This article is in the public domain.
------------------------------
Message-ID: <ALMS.90Mar8103308@brazil.cambridge.apple.com>
Date: 8 Mar 90 15:33:08 GMT
From: "Andrew L. M. Shalit" <cambridge.apple.com!alms@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: (atom? '()) => #t
In article <7079@ubc-cs.UUCP> manis@cs.ubc.ca (Vincent Manis) writes:
In article <1990Mar7.194937.1421@sun.soe.clarkson.edu>
jk0@sun.soe.clarkson.edu (Jason Coughlin) writes:
>Can someone explain the rationale behind treating '() as an atom? It
>seems to me that it should be a pair: it's the empty *list* not the
>empty *atom*.
But remember, a list isn't a pair. It's zero or more pairs connected
together via a cdr chain. In fact, a pair is an object to which the car
and cdr procedures may be applied; it has been considered unkosher for
many years to allow (car '()) and (cdr '()).
Only unkosher in Scheme, not in Common Lisp. Perhaps more
crucially, you have to be able to SET-CAR! and SET-CDR! a pair.
This is something you certainly can't do to the empty list.
-andrew
------------------------------
Message-ID: <542@fsu.scri.fsu.edu>
Date: 8 Mar 90 15:32:50 GMT
From: Eric Pepke <zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!uflorida!mephisto!prism!fsu!gw.scri.fsu.edu!pepke@think.com>
To: scheme@mc.lcs.mit.edu
Subject: Re: in defense of C
In article <1942@skye.ed.ac.uk> jeff@aiai.ed.ac.uk (Jeff Dalton) writes:
> You say this as if it were typical of better compilers on machines
> other than SPARCs, such as, maybe, 68020s. Can they really have safe
> CARs and CDRs, without loss of speed, on a 68020?
I don't know about the internals of any LISP system other than the ones I
have written. In the one I am now writing for the 680x0, one can have
safe CARs and CDRs without loss of speed. One has to test to see if it is
(1) a valid list, or (2) NIL, anyway. So, one just makes that a test for
(1) a valid list, or (2) anything else. In my system, that's testing a
single bit. In case 1, do the job. In case 2, return NIL.
Eric Pepke INTERNET: pepke@gw.scri.fsu.edu
Supercomputer Computations Research Institute MFENET: pepke@fsu
Florida State University SPAN: scri::pepke
Tallahassee, FL 32306-4052 BITNET: pepke@fsu
Disclaimer: My employers seldom even LISTEN to my opinions.
Meta-disclaimer: Any society that needs disclaimers has too many lawyers.
------------------------------
Message-ID: <1990Mar8.115308.6180@hellgate.utah.edu>
Date: 8 Mar 90 18:53:08 GMT
From: Tim Moore <zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!hellgate.utah.edu!cdr.utah.edu!moore@think.com>
To: scheme@mc.lcs.mit.edu
Subject: Re: in defense of C
In article <542@fsu.scri.fsu.edu> pepke@gw.scri.fsu.edu (Eric Pepke) writes:
>In article <1942@skye.ed.ac.uk> jeff@aiai.ed.ac.uk (Jeff Dalton) writes:
>> You say this as if it were typical of better compilers on machines
>> other than SPARCs, such as, maybe, 68020s. Can they really have safe
>> CARs and CDRs, without loss of speed, on a 68020?
>
>I don't know about the internals of any LISP system other than the ones I
>have written. In the one I am now writing for the 680x0, one can have
>safe CARs and CDRs without loss of speed. One has to test to see if it is
>(1) a valid list, or (2) NIL, anyway. So, one just makes that a test for
>(1) a valid list, or (2) anything else. In my system, that's testing a
>single bit. In case 1, do the job. In case 2, return NIL.
>
That's the loss of speed that Jeff is talking about. If you assume
that the argument to CAR or CDR is a cons cell or NIL and you have a
low-tags type scheme, then those operations are 1 instruction long on
a 680x0 (or even less: a base-displacement addressing mode). The NIL
case can be handled with a bit of symbol table trickery. A "safe"
C{A,D}R that checks its argument is going to be slower.
>Eric Pepke INTERNET: pepke@gw.scri.fsu.edu
>Supercomputer Computations Research Institute MFENET: pepke@fsu
>Florida State University SPAN: scri::pepke
>Tallahassee, FL 32306-4052 BITNET: pepke@fsu
>
Tim Moore moore@cs.utah.edu {bellcore,hplabs}!utah-cs!moore
"Ah, youth. Ah, statute of limitations."
-John Waters
------------------------------
Message-ID: <113917@ti-csl.csc.ti.com>
Date: 8 Mar 90 23:41:23 GMT
From: John Gateley <cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!wuarchive!swbatl!texbell!texsun!smunews!ti-csl!m2!gateley@yale-zoo.arpa>
To: scheme@MC.lcs.mit.edu
Subject: Re: in defense of C
In article <542@fsu.scri.fsu.edu> pepke@gw.scri.fsu.edu (Eric Pepke) writes:
|In the one I am now writing for the 680x0, one can have
|safe CARs and CDRs without loss of speed.
|So, one just makes that a test for
|(1) a valid list, or (2) anything else. In my system, that's testing a
|single bit. In case 1, do the job. In case 2, return NIL.
|Eric Pepke INTERNET: pepke@gw.scri.fsu.edu
But this is NOT safe: consider the following code:
(defun foo ()
(if (car 3)
(tear-down-the-berlin-wall)
(bomb-the-soviets)))
Your implementation will bomb the soviets! I understand that your
implementation will not crash due to garbage pointers, but I
don't think "safe" is a good term to apply here.
John
gateley@m2.csc.ti.com
------------------------------
Message-ID: <7385@latcs1.oz.au>
Date: 9 Mar 90 01:08:43 GMT
From: "Jacob L. Cybulski" <uhccux!munnari.oz.au!murtoa.cs.mu.oz.au!ditmela!latcs1!jacob@AMES.ARC.NASA.GOV>
To: scheme@mc.lcs.mit.edu
Subject: Re: (atom? '()) => #t
In article <1990Mar7.194937.1421@sun.soe.clarkson.edu>, jk0@sun.soe.clarkson.edu (Jason Coughlin) writes:
> Can someone explain the rationale behind treating '() as an atom? It
> seems to me that it should be a pair: it's the empty *list* not the
> empty *atom*.
>
When you look at lists from a purely functional point of view then
any list is the result of CONS, whereas () is a primitive object,
thus an atom. A good example of this approach was given in Abelson,
Sussman and Sussman's book, where CONS, CAR and CDR are implemented
functionally as follows :-
(define (cons x y)
(define (dispatch m)
(cond ((= m 0) x)
((= m 1) y)
(else (error "Arg not 0 nor 1 -- CONS" m))))
dispatch)
(define (car z)(z 0))
(define (cdr z)(z 1))
As you can see () does not even appear anywhere in this
definition, it may be viewed as a constant which customarily
appears at the end of the sequencs of pairs (which we call a list).
Jacob o | o
\_/
------------------------------
Message-ID: <14236@cbnewsc.ATT.COM>
Date: 8 Mar 90 15:49:57 GMT
From: "lawrence.g.mayka" <att!cbnewsc!lgm@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: in defense of C
In article <1942@skye.ed.ac.uk> jeff@aiai.UUCP (Jeff Dalton) writes:
>In article <14112@cbnewsc.ATT.COM> lgm@cbnewsc.ATT.COM (lawrence.g.mayka,ihp,) writes:
> >One of the most important quality measures of a Common Lisp
> >compiler is the level of safety it supports without an undue
> >sacrifice in execution speed. The better CL implementations score
> >quite highly on this scale, especially on newer processor
> >architectures such as SPARC. For example, the better compilers
> >indeed ensure that CAR and CDR are only applied to lists, without
> >a loss of execution speed and even though a CL implementation must
> >permit one to apply CAR and CDR to the symbol NIL.
>
>You say this as if it were typical of better compilers on machines
>other than SPARCs, such as, maybe, 68020s. Can they really have safe
>CARs and CDRs, without loss of speed, on a 68020? If so, I would
>expect that safety to remain even if I set saftey=0, but that doesn't
>seem to be what happens. Moreover, how many of the SPARC compilers
>can do this? I suspect it's only one or two of them.
You may be right. The particular compilation "trick" I've seen
relies on the processor hardware to trap a fullword-size reference
to a machine address not aligned on a fullword boundary. But if,
as I think is true, the 68020 silently satisfies unaligned pointer
references, this particular technique will indeed be ineffective
on that architecture.
All the more reason to upgrade to a RISC-based computer...
Lawrence G. Mayka
AT&T Bell Laboratories
lgm@ihlpf.att.com
Standard disclaimer.
------------------------------
Message-ID: <82000008@uicbert.eecs.uic.edu>
Date: 9 Mar 90 10:40:06 GMT
From: cs.utexas.edu!uwm.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!uicbert.eecs.uic.edu!lam@yale-zoo.arpa
To: scheme@mc.lcs.mit.edu
Subject: small pgms using big data?
I'm looking for scheme programs to test different aspects of garbage
collectors. For now, I'm looking for *small* programs that operate
on *large* amounts of data. Programs that have some sort of size
parameter, to scale the problem size and data usage, would be ideal.
One such program (which we already have) is an n queens program,
where we can scale the problem size by setting n to different values.
(Don't offer us that one, though -- we've already got it.)
Other good programs would be things like chess programs with alpha-
beta pruning, which we could scale by setting the number of lookahead
moves.
Branch-and-bound and transitive closure kinds of things would
be interesting, especially if the inputs are in a fairly simple
format. (E.g., the dataflow phase of a compiler would be good,
if it wouldn't be hard to isolate and port to a very vanilla
Scheme, and we could just read representative inputs from
a file or something.)
Our main desiderata are:
1) that the programs be fairly easily ported (in particular, to
a Scheme with very few extensions, and in which #F and '()
are two distinct objects.)
2) scalability via either a simple parameter or choice of
input problem
3) representativeness of some important class of algorithms --
e.g., things that explore state spaces in something like
a depth-first way, where only the representations on
the current path are live, and those that keep around
representations of things already reached, like branch-
and-bound.
(I don't mean to overstress AI-type algorithms -- these are just
examples. We just want small programs whose overall processing
patterns resemble those of more serious programs, and which scale.)
Ultimately, we want to put together a set of benchmark programs
that can be used to stress different aspects of a garbage
collector over a range of problem sizes.
Please reply via email. If there's interest, I'll summarize
to the net.
-- Mike Lam
Software Systems Laboratory lam@bert.eecs.uic.edu
EECS Dept. (m/c 154)
University of Illinois at Chicago
Box 4348 Chicago IL 60680
------------------------------
Message-ID: <82000007@uicbert.eecs.uic.edu>
Date: 8 Mar 90 20:36:00 GMT
From: snorkelwacker!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!brutus.cs.uiuc.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!uicbert.eecs.uic.edu!lam@bloom-beacon.mit.edu
To: scheme@mc.lcs.mit.edu
Subject: Re: in defense of C
/* Written 1:35 pm Mar 1, 1990 by gjc@mitech.COM in uicbert.eecs.uic.edu:comp.lang.scheme */
/* ---------- "in defense of C" ---------- */
In defense of C?
(Or an apology for small extensible languages with minimal overhead
and minimal required runtime libraries).
The key here is the phrase "equivalent program in Pascal" coupled
with the extremely important suggestion I made, which is that C
could be used like you use lisp.
You say C has no array bounds checking. (In a way, big deal,
certainly the Lispmachines had extremely good low-level checking
of that nature, but it didn't keep the software or user from
being able to "... let machines crash or behave strangely" as Steele puts it).
It is so easy to build up error-checking routines from
non-error-checking primitives. Is that not what we do in lisp? (Maybe
we only *used* to do it, a lost art?) Here are some declarations from
some code I use every day:
struct bitarray
{long width; long height; char *data;};
int bitaref(struct bitarray *,int,int);
void bitaset(struct bitarray *,int,int,int);
struct bitarray *cons_bitarray(long,long);
Now, with prototype-enforcement there is absolutely no way my program is
going to crash or behave badly if I use these three guys, cons_bitarray,
bitaref and bitaset.
The prototype-enforcement makes sure I'm not calling these on data
that are not bit arrays and integers. My C-compiler can inline these
and remove redundant error checking in many case.
I claim: A good engineer can generate a much richer and more useful set of
subroutines of this nature than found in ANY LANGUAGE DESIGNED BY COMMITTEE.
.. especially compared to those those languages who's references manuals
start overflowing into multiple volumes!
On the subject of I/O primitives. "Gets" is one of those line-at-a-time
(what I called mainframe-style) procedures. Not what I had in mind (also,
not really what you should be calling primitive). Better to think in terms
of getc and putc, or read and write, or XGetNextEvent.
-gjc
p.s. "... let machines crash or behave strangely", personally *no* I
don't use the Macintosh and try to avoid writing Unix kernel code.
/* End of text from uicbert.eecs.uic.edu:comp.lang.scheme */
------------------------------
End of Scheme Digest
********************
∂11-Mar-90 0015 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #323
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 11 Mar 90 00:15:21 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA06238; Sun, 11 Mar 90 03:12:21 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Sun, 11 Mar 90 03:11:26 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa29469;
11 Mar 90 3:06 EST
Message-Id: <DIGEST.184.900311.021947.62@MC.LCS.MIT.EDU>
Date: 11 Mar 90 02:19:46 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #323
Scheme Digest #323 11 Mar 90 02:19:46 EST
Today's Topics:
call/cc (2 messages)
in defense of C
Lisp implementation techniques and tools (looking for)
----------------------------------------------------------------------
Message-ID: <38402@iuvax.cs.indiana.edu>
Date: 10 Mar 90 02:39:35 GMT
From: Pete Harlan <silver!harlan@iuvax.cs.indiana.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: call/cc
sane@cs.uiuc.edu (Aamod Sane) writes:
| I tried to understand the operation of call/cc from Dybvigs text
|and the R3.99 without success. Can someone give a good explanation here or
|a reference? It is said that the interepreter uses continuations which are
|not visible normally etc. but I dont quite get this.
Chapters 16 and 17 of _Scheme and the Art of Programming_, by
Springer/Friedman, McGraw-Hill/MIT Press, gives a thorough
introduction to understanding call/cc. It includes many examples of
its use, and many exercises for practicing. I highly recommend it.
---
Pete Harlan
harlan@silver.ucs.indiana.edu
------------------------------
Message-ID: <546@fsu.scri.fsu.edu>
Date: 9 Mar 90 13:58:07 GMT
From: Eric Pepke <mephisto!prism!fsu!gw.scri.fsu.edu!pepke@rutgers.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: in defense of C
Sorry; I misunderstood the controversy. I feel like Emily Latella.
"Never mind!"
Eric Pepke INTERNET: pepke@gw.scri.fsu.edu
Supercomputer Computations Research Institute MFENET: pepke@fsu
Florida State University SPAN: scri::pepke
Tallahassee, FL 32306-4052 BITNET: pepke@fsu
Disclaimer: My employers seldom even LISTEN to my opinions.
Meta-disclaimer: Any society that needs disclaimers has too many lawyers.
------------------------------
Message-ID: <QZyGkmy00Vsn0_xmFV@andrew.cmu.edu>
Date: 10 Mar 90 16:32:50 GMT
From: Robert Steven Glickstein <bobg+@andrew.cmu.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: call/cc
When I was first trying to grok continuations as a Scheme novitiate, I
found the sequence below very enlightening. Try to understand what's
going on here; I'll post a detailed description in a day or two.
> (define (identity-fn x) x)
> (define (current-continuation) (call/cc identity-fn))
> (define foo (current-continuation))
> foo
#[Continuation]
> (foo 10)
> foo
10
______________
Bob Glickstein | Internet: bobg@andrew.cmu.edu
Information Technology Center | Bitnet: bobg%andrew@cmuccvma.bitnet
Carnegie Mellon University | UUCP: ...!harvard!andrew.cmu.edu!bobg
Pittsburgh, PA 15213-3890 |
(412) 268-6743 | Sinners can repent, but stupid is forever
------------------------------
Message-ID: <9003102220.AA03912@schizo.samsung.com>
Date: Fri, 9 Mar 90 20:05:29 EDT
From: gjc@mitech.com
Reply-To: gjc@mitech.com
To: Scheme@mc.lcs.mit.edu
Subject: Lisp implementation techniques and tools (looking for)
It is not unusual to want to have an interpreted language as a front-end
for intensive numerical computations.
I know of at least one case of a serious physics simulation efforts
at Livemore Labs that uses Scheme as a toplevel for both interactive
and Batch jobs for programs mostly written in C.
Even a casual look at more advanced solution/simulation techniques
for partial differential equations shows a rather heavy use
of LIST STRUCTURE, even if this codes are written in FORTRAN.
But considering what data to have as lists, what to have as arrays,
how much copying to do, compacting, data movement, the impact
of virtual memory or the need to swap data in non-virtual memory
implementations (e.g. the CRAY), this can all get rather hairy,
and you have to connsider the low-level representations in detail.
(Consider the 5-way memory interleave on the CRAY-1).
I'm a proponent of keeping the initial lisp part of the program
as small and simple as possible, and to allow the lisp/c subroutine
interface be as NATURAL as possible.
My studies indicate that SIOD is better than XLISP, XSCHEME, or ELK
inn these matters.
Anyone who wants to can consider for themselves:
Anonymous FTP to BU.EDU, cd to users/gjc and get siod-v2.3-shar.
-gjc
------------------------------
End of Scheme Digest
********************
∂11-Mar-90 1404 rauen@brokaw.lcs.mit.edu Re: modules
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 11 Mar 90 14:04:28 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA10398; Sun, 11 Mar 90 16:59:47 EST
Received: from brokaw.LCS.MIT.EDU (brokaw.lcs.mit.edu) by zurich.ai.mit.edu; Sun, 11 Mar 90 16:58:53 est
Received: by brokaw.LCS.MIT.EDU
id AA09375; Sun, 11 Mar 90 16:59:10 EST
Date: Sun, 11 Mar 90 16:59:10 EST
From: rauen@brokaw.lcs.mit.edu (James R. Rauen)
Message-Id: <9003112159.AA09375@brokaw.LCS.MIT.EDU>
To: rrrs-authors@zurich.ai.mit.edu
Cc: rauen@brokaw.lcs.mit.edu
Subject: Re: modules
John Ramsdell, Fri, 23 Feb 90 13:22:04 EST:
> Before I form an opinion on this proposal, please answer the
> following question. Many module systems provide some sort of generic
> or parameterized module facility. Standard ML has functors and Ada
> has generics. Does this proposal provide parametric modules and can
> they be instantiated using a set of mutually recursive module
> declarations? If parameterized modules were left out purposely,
> please explain why.
In short, no. The module system is not that ambitious. We are using
modules to provide a static mechanism for controlling the access that
different parts of a program have to each other. We are not using
modules to provide data abstraction or (object-oriented-ish) classes.
I can think of three kinds of things offhand that one might want to
parametrize a module over: types, values, and implementations. Type
parametrization isn't as useful in Scheme as it is in ML or Ada
because of Scheme's latent typing. The module system lets you
parametrize over implementations (by means of interface
specifications), but only statically -- there is no way to dynamically
select a particular implementation of an interface specification.
It's true that you gain more expressive power by introducing
parametrized modules. It's a tradeoff; the penalty is a more
complicated semantics. You can keep on adding expressive power by
going all the way to first-class modules, but if you go that far
you've pretty much given up hope on static checking.
Where to draw the line depends on one's goals. Among Scheme Xerox's
goals, simple semantics and static checking outweigh the additional
expressive power of parametrization. What is appropriate for RNRS
might well be (and almost certainly will be!) different.
Jim
∂11-Mar-90 2351 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #324
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 11 Mar 90 23:51:13 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA16067; Mon, 12 Mar 90 02:47:01 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Mon, 12 Mar 90 02:46:14 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa21397;
12 Mar 90 2:37 EST
Message-Id: <DIGEST.184.900312.020446.66@MC.LCS.MIT.EDU>
Date: 12 Mar 90 02:04:45 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #324
Scheme Digest #324 12 Mar 90 02:04:45 EST
Today's Topics:
problems/risks due to programming language, stories requested
in defense of C
----------------------------------------------------------------------
Message-ID: <1771@awdprime.UUCP>
Date: 9 Mar 90 20:13:10 GMT
From: Tony Sanders <samsung!cs.utexas.edu!romp!auschs!d75!awdprime!sanders.austin.ibm.com@think.com>
To: scheme@mc.lcs.mit.edu
Subject: Re: problems/risks due to programming language, stories requested
In article <8218@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
> So is a multi-alternative case, as provided by Ada:
How do you do this in ADA?
switch(n) {
case 0:
count++;
case 1:
ocount++;
case 2:
printf("%d %d\n",count,ocount);
break;
default:
printf("unknown n\n");
break;
}
See how I left out the breaks on purpose.
In ADA you wouldn't be able to do this without duplicating either the
case-expression (they aren't always simple numbers) or the statements.
-- sanders The 11th commandment: "Thou shalt use lint"
For every message of the day, a new improved message will arise to overcome it.
Reply-To: cs.utexas.edu!ibmaus!auschs!sanders.austin.ibm.com!sanders
------------------------------
Message-ID: <9003120358.AA01479@zurich.ai.mit.edu>
Date: Sun, 11 Mar 90 22:58:40 est
From: Chris Hanson <cph@zurich.ai.mit.edu>
To: zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!uflorida!mephisto!prism!fsu!gw.scri.fsu.edu!pepke@think.com
CC: scheme@mc.lcs.mit.edu
Subject: in defense of C
Date: 8 Mar 90 15:32:50 GMT
From: Eric Pepke <zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!uflorida!mephisto!prism!fsu!gw.scri.fsu.edu!pepke@think.com>
In article <1942@skye.ed.ac.uk> jeff@aiai.ed.ac.uk (Jeff Dalton) writes:
> You say this as if it were typical of better compilers on machines
> other than SPARCs, such as, maybe, 68020s. Can they really have safe
> CARs and CDRs, without loss of speed, on a 68020?
I don't know about the internals of any LISP system other than the ones I
have written. In the one I am now writing for the 680x0, one can have
safe CARs and CDRs without loss of speed. One has to test to see if it is
(1) a valid list, or (2) NIL, anyway. So, one just makes that a test for
(1) a valid list, or (2) anything else. In my system, that's testing a
single bit. In case 1, do the job. In case 2, return NIL.
Many 680x0 Scheme compilers offer a mode where no type checking is
performed at all; for these compilers, in that mode, CAR is a single
machine instruction. (Naturally this is dangerous, but there are ways
to recover from segmentation violations and the like.) It sounds like
you mean "without loss of speed" relative to something that is already
slower than this. I believe that type-safe compiled code will
necessarily be slower than than non-type-checking compiled code on the
680x0.
------------------------------
End of Scheme Digest
********************
∂13-Mar-90 0045 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #325
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 13 Mar 90 00:45:20 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA09109; Tue, 13 Mar 90 03:43:54 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Tue, 13 Mar 90 03:43:04 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa01190;
13 Mar 90 3:30 EST
Message-Id: <DIGEST.184.900313.030455.69@MC.LCS.MIT.EDU>
Date: 13 Mar 90 03:04:55 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #325
Scheme Digest #325 13 Mar 90 03:04:55 EST
Today's Topics:
Correct LisP (was Re: in defense of C) (3 messages)
small pgms using big data?
----------------------------------------------------------------------
Message-ID: <12572711825024@AIDA.CSD.UU.SE>
Date: 11 Mar 90 02:08:46 GMT
From: Johnny Billquist <eru!luth!sunic!bmc!kuling!aida.csd.uu.se!d89.johnny-billquist@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: Correct LisP (was Re: in defense of C)
In article <14112@cbnewsc.ATT.COM> lgm@cbnewsc.ATT.COM (lawrence.g.mayka,ihp,) writes:
>One of the most important quality measures of a Common Lisp
>compiler is the level of safety it supports without an undue
>sacrifice in execution speed. The better CL implementations score
>quite highly on this scale, especially on newer processor
>architectures such as SPARC. For example, the better compilers
>indeed ensure that CAR and CDR are only applied to lists, without
>a loss of execution speed and even though a CL implementation must
>permit one to apply CAR and CDR to the symbol NIL.
You might consider me picky, but someone might feel this is
important.
The correct argument to CAR and CDR is *not* lists, but
s-expr (punctuated pairs to be specific). The fact that most
(if not all) LisPs implement lists by punctuated pairs
is a feature you should not rely upon. That is why the
functions FIRST and REST exists. Sure, they do just CAR
and CDR, but what if you stumles upon a LisP which implement
lists in another way? If you should do it *really* right,
CAR and CDR should not be able to work on lists at all,
however convenient it might be.
Anybody who cares to flame can do it to me personally.
======================================================================
Everybody know that the DECstation is a pdp8, which is a RISC,
but where did MIPS computers get into it?
- Johnny Billquist
D89.JOHNNY-BILLQUIST@AIDA.CSD.UU.SE
======================================================================
------------------------------
Message-ID: <9003121647.AA26364@garlic.Stanford.EDU>
Date: Mon, 12 Mar 90 08:47:04 PST
From: Morris Katz <mkatz@garlic.stanford.edu>
To: lam@uicbert.eecs.uic.edu
CC: scheme@mc.lcs.mit.edu
Subject: small pgms using big data?
Date: 9 Mar 90 10:40:06 GMT
From: cs.utexas.edu!uwm.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!uicbert.eecs.uic.edu!lam@yale-zoo.arpa
I'm looking for scheme programs to test different aspects of garbage
collectors.
I am always trying o get sample programs to test my parallel Scheme system.
Could I get a copy of any Scheme programs which you are sent? I am afraid that
i don't have any programs to offer you as my current test programs all seem to
be compute, rather than data, intensive.
------------------------------------------------------------------------------
Morry Katz
katz@cs.stanford.edu
------------------------------------------------------------------------------
------------------------------
Message-ID: <1990Mar12.104518.1412@hellgate.utah.edu>
Date: 12 Mar 90 17:45:18 GMT
From: Tim Moore <cambridge.apple.com!emory!samsung!cs.utexas.edu!hellgate.utah.edu!cdr.utah.edu!moore@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: Correct LisP (was Re: in defense of C)
In article <12572711825024@AIDA.CSD.UU.SE> D89.JOHNNY-BILLQUIST@AIDA.CSD.UU.SE (Johnny Billquist) writes:
>In article <14112@cbnewsc.ATT.COM> lgm@cbnewsc.ATT.COM (lawrence.g.mayka,ihp,) writes:
>The correct argument to CAR and CDR is *not* lists, but
>s-expr (punctuated pairs to be specific). The fact that most
>(if not all) LisPs implement lists by punctuated pairs
>is a feature you should not rely upon. That is why the
>functions FIRST and REST exists. Sure, they do just CAR
>and CDR, but what if you stumles upon a LisP which implement
>lists in another way? If you should do it *really* right,
>CAR and CDR should not be able to work on lists at all,
>however convenient it might be.
>
>Anybody who cares to flame can do it to me personally.
I don't know what Lisps you're refering to, but Common Lisp isn't one
of them. The argument to CAR and CDR is LISTP, which means its either
a cons pair or NIL. How could lists be implemented in some other way?
If some sort of cdr-coding trick or array scheme is used internally in the
implementation, CAR and CDR better still work, or the implementation
is quite broken.
FIRST and REST are for quiche eaters :-) Or, with only have a smiley,
for non-Lisp programmers who are slumming.
>D89.JOHNNY-BILLQUIST@AIDA.CSD.UU.SE
Tim Moore moore@cs.utah.edu {bellcore,hplabs}!utah-cs!moore
"Ah, youth. Ah, statute of limitations."
-John Waters
------------------------------
Message-ID: <2452@quiche.cs.mcgill.ca>
Date: 12 Mar 90 21:47:54 GMT
From: Ronald BODKIN <samsung!cs.utexas.edu!jarvis.csri.toronto.edu!clyde.concordia.ca!mcgill-vision!quiche!utility@think.com>
To: scheme@mc.lcs.mit.edu
Subject: Re: Correct LisP (was Re: in defense of C)
In article <1990Mar12.104518.1412@hellgate.utah.edu> moore%cdr.utah.edu@cs.utah.edu (Tim Moore) writes:
>I don't know what Lisps you're refering to, but Common Lisp isn't one
>of them. The argument to CAR and CDR is LISTP, which means its either
>a cons pair or NIL. How could lists be implemented in some other way?
>If some sort of cdr-coding trick or array scheme is used internally in the
>implementation, CAR and CDR better still work, or the implementation
>is quite broken.
>
>FIRST and REST are for quiche eaters :-) Or, with only have a smiley,
>for non-Lisp programmers who are slumming.
The problem with this is that you lose something conceptually.
I don't think anyone will ever invent a lisp where lists aren't cons'd
together (can you imagine how little extant lisp code would work).
However, the author of Anatomy of Lisp, makes a good point that if you
are trying to deal with abstract things (e.g. lists) then don't "pun"
and say "its really just a ..." The question does arise, however,
whether or not car/cdr are invalid peeking or whether or not they are
so well established that we can consider them overlloaded. I certainly
use them (if only due to the convenience of cXXXr) and if one wasn't
to use them, then one would have to replace cons and just about anything
which can be used on dotted pairs. The issue gets more emphatic when
people start to say "well I know that a window structure is just a list:
(x y dx dy textcolor)" and rely on this kind of thing.
Ron
------------------------------
End of Scheme Digest
********************
∂14-Mar-90 0057 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #326
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 14 Mar 90 00:57:43 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA29339; Wed, 14 Mar 90 03:56:54 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Wed, 14 Mar 90 03:56:03 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa02097;
14 Mar 90 3:31 EST
Message-Id: <DIGEST.184.900314.025002.75@MC.LCS.MIT.EDU>
Date: 14 Mar 90 02:50:02 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #326
Scheme Digest #326 14 Mar 90 02:50:02 EST
Today's Topics:
(atom? '()) => error
(atom? '()) => #t
Correct LisP (was Re: in defense of C)
Finding all functions that are currently defined.
Where can I Get Scheme-in-LISP?
----------------------------------------------------------------------
Message-ID: <9003131055.aa18415@mintaka.lcs.mit.edu>
Date: Tue, 13 Mar 90 06:44 PST
From: RDAVIS%SCU.BITNET@mitvma.mit.edu
To: scheme@lcs.mit.edu
Subject: (atom? '()) => error
One more thing...
Actually, according to revised↑3.99, it is not the case that
(atom? '()) => #T
because atom? is undefined. The empty list is represented as '(), NOT
as the symbol NIL. NIL is treated the same as any other symbol, i.e., it
is initially undefined.
(null? '()) => #T
and
(symbol? '()) => ()
which may please those who did not want the empty list treated the same
way symbols were treated by atom?.
Ruth E. Davis
------------------------------
Message-ID: <9003131152.aa20965@mintaka.lcs.mit.edu>
Date: Tue, 13 Mar 90 06:21 PST
From: RDAVIS%SCU.BITNET@mitvma.mit.edu
To: scheme@lcs.mit.edu
Subject: (atom? '()) => #t
In article <1990Mar7.194937.1421@sun.soe.clarkson.edu>, jk0@sun.soe.clarkson.edu
(Jason Coughlin) writes:
> Can someone explain the rationale behind treating '() as an atom? It
> seems to me that it should be a pair: it's the empty *list* not the
> empty *atom*.
>
Jacob L. Cybulski replies:
> When you look at lists from a purely functional point of view then
> any list is the result of CONS, whereas () is a primitive object,
> thus an atom....
and goes on to define the functional implementation of PAIRS
Vincent Mannis writes:
> But remember, a list isn't a pair.
EXACTLY!!! but then he goes on to say...
> It's zero or more pairs connected together via a cdr chain.
NO!!
I am truly amazed at the apparent confusion between the data structure
LIST and its representation via PAIRs. LIST is an inductively defined
structure:
1) basis case: the-empty-list is a LIST
2) constructive case: if L is a LIST, then the result of
adding X to the front L is a LIST.
A very convenient REPRESENTATION of this data structure is defined
using the atom NIL for the-empty-list, and the PAIR (or SYMBOLIC
EXPRESSION) constructor CONS for the list constructor. A different
representation could be chosen, but a list is still a list.
Perhaps the (intellectual) confusion could be avoided by using
LIST-CONS, FIRST, and REST, instead of CONS, CAR and CDR. In terms of
implementation, one is unlikely to define and use a predicate IS-LIST?
as it would have to cdr-down the pair it is given to see if it started
with NIL.
Victor Mannis also points out, correctly:
> In fact, a pair is an object to which the car
> and cdr procedures may be applied; it has been considered unkosher for
> many years to allow (car '()) and (cdr '())."
to which Andrew Shalit replies:
> Only unkosher in Scheme, not in Common Lisp.
"unkosher" is a very subjective term. Those who consider taking car and
cdr of nil to be unkosher (myself included), consider it so in Scheme and
in Common Lisp (and UCI-, Mac-, Inter-, Rutgers-, Franz-, TLC-, PSL, 1.6,...
1.5). Even when cdr of an atom gets you its property list, it is not
a nice thing to do - relying on implementation details. But all of this
goes back to age old arguments of the merits of "pure" lisp vs incredibly
powerful hacking. I am reminded of Drew McDermott's comment at the 1980
LISP Conference that what he really liked about LISP was that "I can feel
the bits between my toes". but I digress...
Ruth E. Davis
------------------------------
Message-ID: <14343@cbnewsc.ATT.COM>
Date: 13 Mar 90 14:05:37 GMT
From: "lawrence.g.mayka" <att!cbnewsc!lgm@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: Correct LisP (was Re: in defense of C)
In article <12572711825024@AIDA.CSD.UU.SE> D89.JOHNNY-BILLQUIST@AIDA.CSD.UU.SE (Johnny Billquist) writes:
>The correct argument to CAR and CDR is *not* lists, but
>s-expr (punctuated pairs to be specific). The fact that most
>(if not all) LisPs implement lists by punctuated pairs
>is a feature you should not rely upon. That is why the
>functions FIRST and REST exists. Sure, they do just CAR
>and CDR, but what if you stumles upon a LisP which implement
>lists in another way? If you should do it *really* right,
>CAR and CDR should not be able to work on lists at all,
>however convenient it might be.
Your argument is conceptually appealing, and well describes my own
programming practice: I use FIRST and REST for the ubiquitous
list, and reserve CAR and CDR for intentional dotted pairs (such
as the constituents of an association list). Formally, however, I
must quote "Common Lisp: the Language - Second Edition":
p. 415: "FIRST is the same as CAR, SECOND is the same
as CADR..."
p. 416: "REST means the same as CDR but mnemonically
complements FIRST."
Apparently the connection between dotted pairs and lists is deeply
ingrained into Common Lisp.
Lawrence G. Mayka
AT&T Bell Laboratories
lgm@ihlpf.att.com
Standard disclaimer.
------------------------------
Message-ID: <11703@thor.acc.stolaf.edu>
Date: 13 Mar 90 17:23:13 GMT
From: tut.cis.ohio-state.edu!cs.utexas.edu!uwm.edu!srcsip!nic.MR.NET!thor.acc.stolaf.edu!sundberg@purdue.edu
To: scheme@mc.lcs.mit.edu
Subject: Finding all functions that are currently defined.
I'm a beginner with scheme so this is probably an easy question.
I was wondering if a function exists that will tell me all
of the functions that are currently defined?
Ex:
(name-of-the-magic-function)
car
cdr
cons
.
.
.
member?
rember
.
.
.
Does this function exist?
Because this problem is probably so easy it would probably save
a lot of other people's time if you email to me and then I can
just post the replies in their bare form.
Thanks in advance.
===============================================================
sundberg@thor.acc.stolaf.edu John Sundberg
"Can wec whats under vour hood" St Olaf College
Hello I love you won't you tell me Northfield,MN 55057
your name? -Jim and friends (507)663-6431
===============================================================
------------------------------
Message-ID: <22343@super.ORG>
Date: 12 Mar 90 02:31:09 GMT
From: Peter C Olsen <super!pcolsen@uunet.uu.net>
To: scheme@mc.lcs.mit.edu
Subject: Where can I Get Scheme-in-LISP?
I'm looking for an implementation of Scheme written in Common Lisp.
I've recently managed to ``cumshaw'' two ``surplus'' Symbolics Lisp
machines where I work and I much prefer working in Scheme to working in
Common Lisp. Does anyone know where I can get a Scheme interpreter written
in CL to run on them?
Thanks!
+-------------------------------+--------------------------------------------+
| Peter Olsen | ``Engineering is the art of using |
| pcolsen@super.super.org | mathematics and the physical sciences |
| uunet!super!pcolsen | to improve the quality of life.'' |
+-------------------------------+--------------------------------------------+
------------------------------
End of Scheme Digest
********************
∂15-Mar-90 0034 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #327
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 15 Mar 90 00:34:14 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA19626; Thu, 15 Mar 90 03:32:20 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Thu, 15 Mar 90 03:31:13 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa00662;
15 Mar 90 3:13 EST
Message-Id: <DIGEST.184.900315.023503.81@MC.LCS.MIT.EDU>
Date: 15 Mar 90 02:35:03 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #327
Scheme Digest #327 15 Mar 90 02:35:03 EST
Today's Topics:
call/cc
Where to get mit cscheme 7.0 (2 messages)
problems/risks due to programming language, stories requested
Call for votes: comp.lang.functional
Scheme Digest #324
Safe Scheme primops
----------------------------------------------------------------------
Message-ID: <4459@daffy.cs.wisc.edu>
Date: 14 Mar 90 07:49:20 GMT
From: Rick Schaut <daffy!cat9.cs.wisc.edu!schaut@speedy.wisc.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: call/cc
In article <1990Mar8.064319.28399@brutus.cs.uiuc.edu> sane@clitus.cs.uiuc.edu (Aamod Sane) writes:
| Beginners question:
|
| I tried to understand the operation of call/cc from Dybvigs text
| and the R3.99 without success. Can someone give a good explanation here or
| a reference? It is said that the interepreter uses continuations which are
| not visible normally etc. but I dont quite get this.
Most respondants have answered this portion, so I'll not add to the foray.
| I would also like examples/references on the Continuation
| Passing style (just building of lambdas, not the call/cc variety).
| I know of examples such as gcd of a list where you can escape
| if a 1 is encountered without doing any computation, by building lambdas
| and using them only if 1 is not found.
But, noone has answered this yet, so here goes. The following is a function
that maps a function to a "tree" where a list represents a node in the
tree. The top level list is the root node, and intermediate level lists
are intermediate nodes (and are the children of the list which contains
them), and any atoms are the leaves. For example, (1 (2 3) (4 (5 6)) 7)
is one such tree.
The catch is that the mapped function may return a value indicating that
the value that was passed to it was not acceptable (for whatever reason).
The tree-map function, then, should return a list of the form
('not-yet <unacceptable input value>).
If the map was applied successfully, then the return sould be
('done <mapped tree>).
The code that implements this is:
(define (tree-map filter tree)
(let ((result (tree-mapc filter tree (lambda(x)x))))
(if (and (not (null? result)) (list? result) (equal? 'not-yet (car result)))
result
(list 'done (revall result)))))
(define (tree-mapc filter tree cont)
(cond
((null? tree) (cont '()))
((atom? tree)
(let ((result (filter tree)))
(if (equal? result '*not-acceptable*)
(list 'not-yet tree)
result)))
(else
; first, map the car of the tree using a fresh continuation
; i.e. build a continuation for the sublist
(let ((result (tree-mapc filter (car tree) (lambda(x)x))))
(if (and
(not (null? result))
(list? result)
(equal? 'not-yet (car result)))
result ;<- stop the recursion here, we've found an error
;else cons the result onto the current continuation and map the cdr
(tree-mapc filter (cdr tree) (lambda(x)(cons result (cont x)))))))))
(define (revall l)
(cond ((atom? l) l)
((null? l) l)
(else
(let ((e (if (list? (car l)) (revall (car l)) (car l))))
(append (revall (cdr l)) (list e))))))
This is _very_ ugly code, and sufficient reason to understand and use
call/cc. The equivalent code that uses call/cc is:
(define (tree-map filter tree)
(let ((result (call/cc (lambda(return)(tree-mapc filter tree return)))))
(if (and (not (null? result)) (list? result) (equal? 'not-yet (car result)))
result
(list 'done result))))
(define (tree-mapc filter tree return)
(cond
((null? tree) '())
((atom? tree)
(let ((result (filter tree)))
(if (equal? result '*not-acceptable*)
(tree-mapc
filter
(call/cc (lambda(context)(return (list 'not-yet tree context))))
return)
result)))
(else (cons
(tree-mapc filter (car tree) return)
(tree-mapc filter (cdr tree) return)))))
Note also that this version uses call/cc to return control to the top-level
tree-map function. This allows the calling routine to provide a substitute
value back to tree-map, and tree-map will continue the original computation
using the substituted value. As you mentioned, interpreters use this same
construct when they encounter an error. They use a call/cc to invoke a
debugging routine which, in turn, allows the user to correct the data/code.
The corrections are then dropped back into the computation in which the
error occurred and the computation is restarted where it left off. If your
interpreter has a continue option in its break package, then it is using
a call/cc in the error trap.
--
Rick (schaut@garfield.cs.wisc.edu)
"I'm a theory geek; we use Turing machines!"--Gary Lewandowski
------------------------------
Message-ID: <22476@metropolis.super.ORG>
Date: 14 Mar 90 02:40:43 GMT
From: Peter C Olsen <super!pcolsen@uunet.uu.net>
To: scheme@mc.lcs.mit.edu
Subject: Where to get mit cscheme 7.0
Would someone please tell me where I can get the ftp-able
code for mit cscheme-7.0 I need the *whole* thing, including
the code for Edwin.
Thanks
+-------------------------------+--------------------------------------------+
| Peter Olsen | ``Engineering is the art of using |
| pcolsen@super.super.org | mathematics and the physical sciences |
| uunet!super!pcolsen | to improve the quality of life.'' |
+-------------------------------+--------------------------------------------+
------------------------------
Message-ID: <1990Mar14.044656.28854@kaukau.comp.vuw.ac.nz>
Date: 14 Mar 90 04:46:56 GMT
From: Lindsay Groves <mintaka!ogicse!uwm.edu!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!kaukau.comp.vuw.ac.nz!lindsay@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: problems/risks due to programming language, stories requested
In article <1004@micropen>, dave@micropen (David F. Carlson) writes:
> What break does is *very* well defined and is no more prone to
misinterpretation
> that any other non-linear control flow statement in any other PL.
A number of people in this discussion (which I haven't reached the end of yet!)
have said things like this, and appear to be suggesting that because something
is well defined there is no excuse for anyone misusing it. I disagree
with that
and also with the second part of this statement. There are languages in which
any kind of exit has to explicitly name the construct to be exitted -- so there
is no possiblity of consfusion about which construct the exit/break/etc.
applies
to.
> A multi-case switch is very handy in many situations to reduce identical
> treatments for similar cases. That you ask the question of the usefulness
> of break-per-case/multiple-cases implies that you haven't sufficient
experience
> with the construct to judge its merits/weaknesses.
>
> Dijkstra notes that no programming language can prevent a poor
programmer from
> creating bad programs.
So why aren't we all still using FORTRAN (or some older dialect)? Why did we
all think that unlabelled CASE statements (as in Algol-W and Burroughs Algol)
were a big improvement over computed GOTOs in FORTRAN (which is basically what
the switch in C is), or that the labelled CASE statement (as in Pascal) was
a big improvement over that? Maybe the whole of the last 30 years of work in
programming language design has been a dream!!!
Lindsay Groves
------------------------------
Message-ID: <Mar.14.18.06.01.1990.3183@turbo.bio.net>
Date: 13 Mar 90 04:15:13 GMT
From: david carlton <samsung!usc!apple!bionet!turbo.bio.net!harvard.harvard.edu@think.com>
To: scheme@mc.lcs.mit.edu
Subject: Call for votes: comp.lang.functional
Here's the official call for votes for comp.lang.functional. It
will be an unmoderated group for the discussional of functional
programming and functional programming languages. By 'functional
programming' is meant programming without side effects and in a
context where functions are first class objects. It isn't necessary
that the language itself be purely functional, so scheme, ml, etc. are
valid topics for discussion; but only the functional aspects of not
purely functional languages should be discussed.
The voting period will last from March 13 to April 3, inclusive.
Votes should be mailed to carlton@husc4.harvard.edu,
husc6!husc4!carlton, and should contain a subject of the form
i vote {YES, NO} for comp.lang.functional as proposed.
The group will then be created, after a 5 day waiting period, if
100 more YES votes than NO votes are received and if at least 2/3 of
the votes are YES votes.
david carlton
carlton@husc4.harvard.edu
husc6!husc4!carlton
carlton@husc4.bitnet
------------------------------
Message-ID: <9003150314.AA17217@bronto.soar.cs.cmu.edu>
Date: Wed, 14 Mar 90 22:14:13 EST
From: Olin Shivers <shivers@bronto.soar.cs.cmu.edu>
To: Scheme@MINTAKA.LCS.MIT.EDU
Subject: Scheme Digest #324
People have been discussing the trade-offs involved in implementing
Scheme with safe, slow primitive operators, that check for illegal arguments,
and fast, dangerous operators (single instruction CAR, for example):
From: Chris Hanson <cph@zurich.ai.mit.edu>
In article <1942@skye.ed.ac.uk> jeff@aiai.ed.ac.uk (Jeff Dalton) writes:
> You say this as if it were typical of better compilers on machines
> other than SPARCs, such as, maybe, 68020s. Can they really have safe
> CARs and CDRs, without loss of speed, on a 68020?
I believe that type-safe compiled code will necessarily be slower than
than non-type-checking compiled code on the 680x0.
One alternative is to do compile-time analysis to recover the types of
arguments. You can then (hopefully) eliminate many of the run-time safety
checks and still provide full safety with dangerous speed.
For example, suppose you compile the following definition of DELQ:
(define (delq lis elt)
(letrec ((lp (lambda (ans rest)
(if (pair? rest)
(let ((head (car rest)))
(lp (if (eq? head elt) ans (cons head ans))
(cdr rest)))
(reverse! ans)))))
(lp '() lis)))
You can get a lot of type information from this procedure:
- Flow analysis tells you that ANS is only bound to '(), itself, or
the result of a CONS application, so ANS is always a list.
- In the THEN arm of the IF test, we know that references to REST are
pairs. So the CAR and CDR ops can be compiled without any runtime
error checking, and be guaranteed to work.
So you can compile DELQ safely without any error checking.
Another source of type information is using arguments in safe primops.
For example, in
(lambda (x) ... (car x) ... (cdr x) ...)
If the CAR operation is compiled with error checking, then we know
that code executed *after* the CAR can safely assume X is a pair --
so the CDR can be compiled without error checking.
What you are hoping for in this case is that a compiler that does this
kind of analysis will compile in error checking in the beginning of
a procedure, but by the time you get into the real guts of the procedure,
you'll be able to use information from the early error checking to
safely eliminate the rest of the error checks. Safe like a LispM;
fast like a RISC.
The nice thing about this kind of analysis is that it sort of comes for
free. You've already got all those CAR's and CDR's and +'s and ATAN's and
(IF (PAIR? X) ...)'s sitting there in your code; why not squeeze out
all the information they imply? That's even before you add in declarations...
I've got a CMU tech report that shows how to do this analysis. The analysis
I've got implemented in my toy system, for example, will give you enough
information to completely type-recover the DELQ procedure above. I have not,
however, done large tests, as in: hook the thing into a real compiler, compile
some massive chunk of real code, and measure the speedup over
stupidly-typechecked code (or the slowdown from dangerous code). So just how
much type-recovery analysis buys you has yet to be settled.
In any event, if people are interested, I'd be happy to send them copies of
the report.
Besides compile-time analysis, there are some tricks you can play
with the hardware trap logic to get tag-checking in parallel, even
on stock architectures. In the Screme system that Adams, Pleban
and Vegdahl did for the 88000, they carefully arranged the tags so
that procedure calls to non-procedures would cause a non-aligned
address trap. You can do this with cons cells as well, if your machine
traps on unaligned accesses. If you make the conses be descriptors with
the low two bits 11, then car is "load-word -3(r)" and cdr is
"load-word 1(r)." If the low 2 bits aren't 11, then you'll try to
load a word from a non-word boundary, and the system will trap.
Also, note that safe compilation is not just a Lispy kind of thing to
worry about. The 801 PL.8 compiler ensured complete runtime safety.
All array indexing and pointer dereferencing was checked at run time.
The compiler did range analysis to optimise away the runtime checks.
Ensuring safety meant that they could run multiple processes in the
same address space; system calls to the kernel were just procedure
calls, so system calls and process swaps were very fast.
The merits of handling issues of basic system integrity in the compiler
like the 801 did are debatable, but certainly interesting.
-Olin
P.S. The importance of runtime safety became clear to me one day when a bug in
some compiled T code of mine set the cdr of () to 4. Wow. Just like Fortran...
Everything broke horribly. I fixed the bug in my code, but things kept
crapping out. I spent several hours poring over bug-free code looking for
a bug. When I finally found the problem, I wandered upstairs for a break and
flamed a grad student friend about my "bug." He sat there, at his 3600, and
laughed and laughed. "What? Your Scheme system let you set the cdr of nil?"
Speed isn't everything.
------------------------------
Message-ID: <9003150501.AA17379@bronto.soar.cs.cmu.edu>
Date: Thu, 15 Mar 90 00:01:59 EST
From: Olin Shivers <shivers@bronto.soar.cs.cmu.edu>
To: scheme@zurich.ai.mit.edu
Subject: Safe Scheme primops
People have been discussing the trade-offs involved in implementing
Scheme with safe, slow primitive operators, that check for illegal arguments,
and fast, dangerous operators (single instruction CAR, for example):
From: Chris Hanson <cph@zurich.ai.mit.edu>
In article <1942@skye.ed.ac.uk> jeff@aiai.ed.ac.uk (Jeff Dalton) writes:
> You say this as if it were typical of better compilers on machines
> other than SPARCs, such as, maybe, 68020s. Can they really have safe
> CARs and CDRs, without loss of speed, on a 68020?
I believe that type-safe compiled code will necessarily be slower than
than non-type-checking compiled code on the 680x0.
One alternative is to do compile-time analysis to recover the types of
arguments. You can then (hopefully) eliminate many of the run-time safety
checks and still provide full safety with dangerous speed.
For example, suppose you compile the following definition of DELQ:
(define (delq lis elt)
(letrec ((lp (lambda (ans rest)
(if (pair? rest)
(let ((head (car rest)))
(lp (if (eq? head elt) ans (cons head ans))
(cdr rest)))
(reverse! ans)))))
(lp '() lis)))
You can get a lot of type information from this procedure:
- Flow analysis tells you that ANS is only bound to '(), itself, or
the result of a CONS application, so ANS is always a list.
- In the THEN arm of the IF test, we know that references to REST are
pairs. So the CAR and CDR ops can be compiled without any runtime
error checking, and be guaranteed to work.
So you can compile DELQ safely without any error checking.
Another source of type information is using arguments in safe primops.
For example, in
(lambda (x) ... (car x) ... (cdr x) ...)
If the CAR operation is compiled with error checking, then we know
that code executed *after* the CAR can safely assume X is a pair --
so the CDR can be compiled without error checking.
What you are hoping for in this case is that a compiler that does this
kind of analysis will compile in error checking in the beginning of
a procedure, but by the time you get into the real guts of the procedure,
you'll be able to use information from the early error checking to
safely eliminate the rest of the error checks. Safe like a LispM;
fast like a RISC.
The nice thing about this kind of analysis is that it sort of comes for
free. You've already got all those CAR's and CDR's and +'s and ATAN's and
(IF (PAIR? X) ...)'s sitting there in your code; why not squeeze out
all the information they imply? That's even before you add in declarations...
I've got a CMU tech report that shows how to do this analysis. The analysis
I've got implemented in my toy system will, for example, give you enough
information to completely type-recover the DELQ procedure above. I have not,
however, done large tests, as in: hook the thing into a real compiler, compile
some massive chunk of real code, and measure the speedup over
stupidly-typechecked code (or the slowdown from dangerous code). So just how
much type-recovery analysis buys you has yet to be settled.
In any event, if people are interested, I'd be happy to send them copies of
the report.
Besides compile-time analysis, there are some tricks you can play
with the hardware trap logic to get tag-checking in parallel, even
on stock architectures. In the Screme system that Adams, Pleban
and Vegdahl did for the 88000, they carefully arranged the tags so
that procedure calls to non-procedures would cause a non-aligned
address trap. You can do this with cons cells as well, if your machine
traps on unaligned accesses. If you make the conses be descriptors with
the low two bits 11, then car is "load-word -3(r)" and cdr is
"load-word 1(r)." If the low 2 bits aren't 11, then you'll try to
load a word from a non-word boundary, and the system will trap.
Also, note that safe compilation is not just a Lispy kind of thing to
worry about. The 801 PL.8 compiler ensured complete runtime safety.
All array indexing and pointer dereferencing was checked at run time.
The compiler did range analysis to optimise away the runtime checks.
Ensuring safety meant that they could run multiple processes in the
same address space; system calls to the kernel were just procedure
calls, so system calls and process swaps were very fast.
The merits of handling issues of basic system integrity in the compiler
like the 801 did are debatable, but certainly interesting.
-Olin
P.S. The importance of runtime safety became clear to me one day when a bug in
some compiled T code of mine set the cdr of () to 4. Wow. Just like Fortran...
Everything broke horribly. I fixed the bug in my code, but things kept
crapping out. I spent several hours poring over bug-free code looking for
a bug. When I finally found the problem, I wandered upstairs for a break and
flamed a grad student friend about my "bug." He sat there, at his 3600, and
laughed and laughed. "What? Your Scheme system let you set the cdr of nil?"
Speed isn't everything.
------------------------------
Message-ID: <1990Mar15.051229.3764@diku.dk>
Date: 15 Mar 90 05:12:29 GMT
From: Kim H|glund <mcsun!sunic!dkuug!freja.diku.dk!rimfaxe.diku.dk!shotokan@uunet.uu.net>
To: scheme@mc.lcs.mit.edu
Subject: Re: Where to get mit cscheme 7.0
pcolsen@super.ORG (Peter C Olsen) writes:
>Would someone please tell me where I can get the ftp-able
>code for mit cscheme-7.0 I need the *whole* thing, including
>the code for Edwin.
It is available for ftp from ftp.diku.dk (129.142.96.1) in the
directory /pub/scheme-7.0.
Enjoy,
Kim
_____
Kim Hoeglund E-mail: shotokan@diku.dk
Systems Administrator
Univ of Copenhagen Comp Sci Dept
------------------------------
End of Scheme Digest
********************
∂16-Mar-90 0011 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #328
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 16 Mar 90 00:10:51 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA11782; Fri, 16 Mar 90 03:09:29 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Fri, 16 Mar 90 03:08:23 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa01026;
16 Mar 90 2:52 EST
Message-Id: <DIGEST.184.900316.022006.86@MC.LCS.MIT.EDU>
Date: 16 Mar 90 02:20:05 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #328
Scheme Digest #328 16 Mar 90 02:20:05 EST
Today's Topics:
Where to get mit cscheme 7.0
problems/risks due to programming language, stories requested
IEEE FP NaNs = everything else? (2 messages)
----------------------------------------------------------------------
Message-ID: <9003151645.AA04053@garlic.Stanford.EDU>
Date: Thu, 15 Mar 90 08:45:51 PST
From: Morris Katz <mkatz@garlic.stanford.edu>
To: super!pcolsen@uunet.uu.net
CC: scheme@mc.lcs.mit.edu
Subject: Where to get mit cscheme 7.0
Date: 14 Mar 90 02:40:43 GMT
From: Peter C Olsen <super!pcolsen@uunet.uu.net>
Would someone please tell me where I can get the ftp-able
code for mit cscheme-7.0 I need the *whole* thing, including
the code for Edwin.
It is available on zurich.ai.mit.edu for anonymous ftp in the directory /pub.
I am told that release 7.1 beta will be placed there in about 1 week, as well.
------------------------------------------------------------------------------
Morry Katz
katz@cs.stanford.edu
------------------------------------------------------------------------------
------------------------------
Message-ID: <1819@awdprime.UUCP>
Date: 15 Mar 90 15:31:23 GMT
From: snorkelwacker!tut.cis.ohio-state.edu!cs.utexas.edu!romp!auschs!awdprime!chibacity.austin.ibm.com!jaws@bloom-beacon.mit.edu
To: scheme@mc.lcs.mit.edu
Subject: Re: problems/risks due to programming language, stories requested
Mr Wolf:
C allows you to combine cases that have portions of similiar code
but may have extra lead in code for a specific case:
switch var:
case A:
/* do stuff only case A needs */
case B:
/* do stuff case A and case B need done */
.
.
break;
/* rest of switch */
this construct in impossible to do cleanly in almost every language I have
ever seem, especially ADA.
This kind flexiability is what makes C so powerfull, and dangerous.
You have know what you are doing to do it.
[ Jeff Wilson :: jaws@chibacity.austin.ibm.com ]
[ Consultant from Pencom, Inc. at Human Factors, AWD, IBM Austin. ]
[My comments are wholly my own and as such take them for what they are worth. ]
------------------------------
Message-ID: <1990Mar15.211150.19338@Neon.Stanford.EDU>
Date: 15 Mar 90 21:11:50 GMT
From: Max Hailperin <shelby!neon!max@decwrl.dec.com>
To: scheme@mc.lcs.mit.edu
Subject: IEEE FP NaNs = everything else?
Has anyone explored the possibility of useing IEEE floating-point as a
general representation in a manifestly-typed language, with everything
other than flonums being NaNs (Not-A-Numbers)? On the surface, this
seems both attractive and ridiculous. If I had to make a guess, I'd
guess that the former only took precedence over the latter for serious
crunching on specialized 64-bit machines.
But, the question is, can anyone do better than my 2-minute idle speculation?
Thanks.
------------------------------
Message-ID: <34725@news.Think.COM>
Date: 16 Mar 90 05:41:07 GMT
From: Barry Margolin <barmar@think.com>
To: scheme@mc.lcs.mit.edu
Subject: Re: IEEE FP NaNs = everything else?
In article <1990Mar15.211150.19338@Neon.Stanford.EDU> max@Neon.Stanford.EDU (Max Hailperin) writes:
>Has anyone explored the possibility of useing IEEE floating-point as a
>general representation in a manifestly-typed language, with everything
>other than flonums being NaNs (Not-A-Numbers)?
The IEEE rule is that any arithmetic involving NaNs must result in a NaN.
But if fixnums are implemented as NaNs then this means that (+ 3.0 1) must
evaluate to a NaN rather than 4.0, since this would be (+ 3.0 NaN).
Perhaps, instead of using NaNs for all non-fixnums you should use NaNs for
all non-numbers (NaN *does* stand for Not a Number, so this makes sense).
You could then use signalling NaNs, which would cause ordinary IEEE FP
hardware to trap on things like (+ 3.0 'a).
--
Barry Margolin, Thinking Machines Corp.
barmar@think.com
{uunet,harvard}!think!barmar
------------------------------
End of Scheme Digest
********************
∂17-Mar-90 0108 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #329
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 17 Mar 90 01:08:42 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA29421; Sat, 17 Mar 90 04:02:15 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Sat, 17 Mar 90 04:01:21 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa07898;
17 Mar 90 3:52 EST
Message-Id: <DIGEST.184.900317.031006.4@MC.LCS.MIT.EDU>
Date: 17 Mar 90 03:10:06 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #329
Scheme Digest #329 17 Mar 90 03:10:06 EST
Today's Topics:
Scheme Digest #324
Scheme Digest #328
problems/risks due to programming language, stories requested
Where to get mit cscheme 7.0
call/cc (2 messages)
----------------------------------------------------------------------
Message-ID: <9003161711.AA20180@mojave.Stanford.EDU>
Date: Fri, 16 Mar 90 09:11:08 PST
From: Daniel Weise <daniel@mojave.stanford.edu>
To: shivers@bronto.soar.cs.cmu.edu
CC: Scheme@mintaka.lcs.mit.edu
Subject: Scheme Digest #324
I've got a CMU tech report that shows how to do this analysis. The
analysis I've got implemented in my toy system, for example, will
give you enough information to completely type-recover the DELQ
procedure above. I have not, however, done large tests, as in: hook
the thing into a real compiler, compile some massive chunk of real
code, and measure the speedup over stupidly-typechecked code (or
the slowdown from dangerous code). So just how much type-recovery
analysis buys you has yet to be settled.
Isn't this the sort of analysis Steenkiste did and reported in LFP 86
and his thesis? He counted the speed with and without type safety, so
his work would be an upper bound on what type analysis could save.
In any event, if people are interested, I'd be happy to send them
copies of the report.
Please do.
Daniel Weise
CIS 207
Stanford, CA 94305
------------------------------
Message-ID: <9003161711.AA13531@zurich.ai.mit.edu>
Date: Fri, 16 Mar 90 12:11:09 est
From: Franklyn Turbak <lyn@zurich.ai.mit.edu>
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #328
In message <1819@awdprime.UUCP>, jaws@chibacity.austin.ibm.com writes:
> C allows you to combine cases that have portions of similiar code
> but may have extra lead in code for a specific case:
>
> switch var:
> case A:
> /* do stuff only case A needs */
>
> case B:
> /* do stuff case A and case B need done */
> .
> .
> break;
>
> /* rest of switch */
>
>
> this construct in impossible to do cleanly in almost every language I have
> ever seem, especially ADA.
It depends on what you mean by "cleanly". Certainly any language
with procedures can capture the above pattern without the
programmer having to duplicate code; that's the essence of
procedural abstraction. E.g., in Scheme we have
(cond
(<case-a-test> (begin (a-stuff <a-args>) (b-stuff <b-args>))
(<case-b-test> (b-stuff <b-args>))
... ; Rest of COND
)
But what about efficiency you ask? My response is: isn't that what
compilers are for? I'd even be willing to insert compiler directives
for in-lining A-STUFF and B-STUFF. Fine, this won't be as space
efficient because the in-lined calls to B-STUFF will be duplicated;
but if you really want that level of control, why not write in assembly?
- Lyn -
------------------------------
Message-ID: <159@uninet.vbo.dec.com>
Date: 16 Mar 90 09:38:46 GMT
From: shlump.nac.dec.com!ryn.esg.dec.com!uninet!kerber!vanavermaet@decwrl.dec.com
To: scheme@mc.lcs.mit.edu
Subject: Re: problems/risks due to programming language, stories requested
with standard_disclaimer; use standard_disclaimer;
In article <1819@awdprime.UUCP>, jaws@chibacity.austin.ibm.com writes...
>This kind flexiability is what makes C so powerfull, and dangerous.
>You have know what you are doing to do it.
I think this is a very sensible remark.
O.K., the semantics are well-defined (as may people have pointed out),
but it still IS dangerous. That (IMHO) is a very important factor (and to me, a
reason not to use C).
Peter Van Avermaet
------------------------------
Message-ID: <9003162254.AA07846@zurich.ai.mit.edu>
Date: Fri, 16 Mar 90 17:54:01 est
From: Chris Hanson <cph@zurich.ai.mit.edu>
To: mkatz@garlic.stanford.edu
CC: scheme@mc.lcs.mit.edu
Subject: Where to get mit cscheme 7.0
Date: Thu, 15 Mar 90 08:45:51 PST
From: Morris Katz <mkatz@garlic.stanford.edu>
Date: 14 Mar 90 02:40:43 GMT
From: Peter C Olsen <super!pcolsen@uunet.uu.net>
Would someone please tell me where I can get the ftp-able
code for mit cscheme-7.0 I need the *whole* thing, including
the code for Edwin.
It is available on zurich.ai.mit.edu for anonymous ftp in the
directory /pub. I am told that release 7.1 beta will be placed
there in about 1 week, as well.
Don't hold your breath. We're all pretty busy and I wouldn't expect
to see any new releases for a month at least.
------------------------------
Message-ID: <5834@brazos.Rice.edu>
Date: 16 Mar 90 23:13:23 GMT
From: Dorai Sitaram <hedera!dorai@rice.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: call/cc
In article <5832@brazos.Rice.edu> dorai@hedera.rice.edu, I perpetrate a typo:
$
$(define tree-map
$ (lambda (filter tree)
$ (let loop ([tree tree])
$ (cond [(null? tree) '()]
$ [(atom? tree)
$ (let ([result (filter tree)])
$ (if (eq? result 'not-acceptable)
$ (F (lambda (context)
$ (list 'not-yet tree context))))
result ;<-- was left out in the original
;↑↑↑↑↑↑
$ )]
$ [else (cons (loop (car tree))
$ (loop (cdr tree)))]))))
--dorai
--
------------------------------------------------------------------------------
It may be that the gulfs will wash us down;
It may be we shall touch the Happy Isles.
------------------------------------------------------------------------------
------------------------------
Message-ID: <5832@brazos.Rice.edu>
Date: 16 Mar 90 22:16:02 GMT
From: Dorai Sitaram <hedera!dorai@rice.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: call/cc
In article <4459@daffy.cs.wisc.edu> schaut@cat9.cs.wisc.edu (Rick Schaut) writes:
>But, noone has answered this yet, so here goes. The following is a function
>that maps a function to a "tree" where a list represents a node in the
>tree. The top level list is the root node, and intermediate level lists
>are intermediate nodes (and are the children of the list which contains
>them), and any atoms are the leaves. For example, (1 (2 3) (4 (5 6)) 7)
>is one such tree.
>
>The catch is that the mapped function may return a value indicating that
>the value that was passed to it was not acceptable (for whatever reason).
>The tree-map function, then, should return a list of the form
>
> ('not-yet <unacceptable input value>).
>
>If the map was applied successfully, then the return sould be
>
> ('done <mapped tree>).
>
>The code that implements this is:
>
[cps-style code deleted]
>
>This is _very_ ugly code, and sufficient reason to understand and use
>call/cc. The equivalent code that uses call/cc is:
>
>(define (tree-map filter tree)
> (let ((result (call/cc (lambda(return)(tree-mapc filter tree return)))))
> (if (and (not (null? result)) (list? result) (equal? 'not-yet (car result)))
> result
> (list 'done result))))
>
>(define (tree-mapc filter tree return)
> (cond
> ((null? tree) '())
> ((atom? tree)
> (let ((result (filter tree)))
> (if (equal? result '*not-acceptable*)
> (tree-mapc
> filter
> (call/cc (lambda(context)(return (list 'not-yet tree context))))
> return)
> result)))
> (else (cons
> (tree-mapc filter (car tree) return)
> (tree-mapc filter (cdr tree) return)))))
>
>Note also that this version uses call/cc to return control to the top-level
>tree-map function. This allows the calling routine to provide a substitute
>value back to tree-map, and tree-map will continue the original computation
>using the substituted value. As you mentioned, interpreters use this same
>construct when they encounter an error. They use a call/cc to invoke a
>debugging routine which, in turn, allows the user to correct the data/code.
>The corrections are then dropped back into the computation in which the
>error occurred and the computation is restarted where it left off. If your
>interpreter has a continue option in its break package, then it is using
>a call/cc in the error trap.
The above is OK, but schleps around too many arguments (filter,
return) for no good reason. Tweaking a bit (and making do without the
'done tag):
(define tree-map
(lambda (filter tree)
(call/cc
(lambda (return)
(let loop ([tree tree])
(cond [(null? tree) '()]
[(atom? tree)
(let ([result (filter tree)])
(if (eq? result 'not-acceptable)
(call/cc
(lambda (context)
(return (list 'not-yet tree context))))
result))]
[else (cons (loop (car tree))
(loop (cdr tree)))]))))))
Ach, the above is _also_ unsatisfactory code: _two_ call/cc's; the
first continuation-grab only contributes towards identifying the
entry-point; the second grab doesn't need to be the whole
continuation, just the difference between the entry and break points.
The so-far best solution, based on one by Felleisen for a similar
tree-walk problem in the paper "Theory and Practice of First-class
Prompts", uses prompt (P) and the functional-continuation analog of
call/cc (F). It certainly is more efficient and IMHO less
sledgehammer-like than the call/cc version:
(define tree-map
(lambda (filter tree)
(let loop ([tree tree])
(cond [(null? tree) '()]
[(atom? tree)
(let ([result (filter tree)])
(if (eq? result 'not-acceptable)
(F (lambda (context)
(list 'not-yet tree context)))))]
[else (cons (loop (car tree))
(loop (cdr tree)))]))))
A sample session:
> (set! result (P (tree-map double-if-not-0 '(1 2 (3 0 (4 0 5))))))
(not-yet 0 #<procedure>)
> (set! result (P ((caddr result) 'debug-insert)))
(not-yet 0 #<procedure>)
> (set! result (P ((caddr result) 'debug-insert-2)))
(2 4 (6 debug-insert (8 debug-insert-2 10)))
--dorai
ps: (define double-if-not-0 (lambda (n)
(if (zero? n) 'not-acceptable (* 2 n))))
ps2: For details about P and F, read the paper, or contact 'most
anybody (once) from Indiana (except maybe the veep). Regular Scheme
doesn't have them, though it should :-].
--
------------------------------------------------------------------------------
It may be that the gulfs will wash us down;
It may be we shall touch the Happy Isles.
------------------------------------------------------------------------------
------------------------------
End of Scheme Digest
********************
∂18-Mar-90 0120 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #330
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 18 Mar 90 01:20:46 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA08310; Sun, 18 Mar 90 04:07:34 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Sun, 18 Mar 90 04:06:49 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa26459;
18 Mar 90 3:54 EST
Message-Id: <DIGEST.184.900318.025507.9@MC.LCS.MIT.EDU>
Date: 18 Mar 90 02:55:07 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #330
Scheme Digest #330 18 Mar 90 02:55:07 EST
Today's Topics:
structure-sharing continuations v I-class P (was Re: call/cc)
----------------------------------------------------------------------
Message-ID: <5855@brazos.Rice.edu>
Date: 17 Mar 90 21:24:06 GMT
From: Dorai Sitaram <hedera!dorai@rice.edu>
To: scheme@mc.lcs.mit.edu
Subject: structure-sharing continuations v I-class P (was Re: call/cc)
$The efficiency issue is not clear. It all depends on the exact
$implementation of call-with-current-continuation. If the
$continuations share structure (as they do in some implementationts),
$the solution based on F is no more time or space efficient.
$
$Note also that your version is shorter because you have moved some of
$the code to the use point (by inserting "prompts").
Hi, I'll take the liberty of answering you on the net too, for
purposes of clarification. This will not prevent the following from
being a bit dense at times, since I'm looking for answers too, not
being an awesome efficiency person (I program in Scheme, right?!).
My (_not_ sole) misgiving about (just) callcc is that because of its
higher-order continuations, it'll end up being just a wee bit too
powerful. Even when it's being used in a purely first-order setting
that requires _no_ structure (heap) at all, let alone structure
sharing, e.g., function/loop exits or just about any _delimiting_ use
of callcc.
Sharing structure between a grabbed continuation k1 and a subsequently
grabbed continuation k2, while fine, doesn't help (IMHO. You can
correct me here.) in the following cases:
a) If k1 is never used but as a delimiter to k2, the structure
allotted to k1 is excess baggage.
b) If k2 is used only to abort to k1, the structure alloted to k2
(whether the whole enchilada or just the difference from k1), is e.b.
I suspect that these things are not compiler-recognizable in a purely
callcc world. (IMHO, of course.) The k1/k2 syndrome shows up in Rick
Schaut's code, and it shows up not infrequently, though not so
clearly, in many other callcc situations.
Now, in a P world, a) is recognizable for the trivial reason that the
user supplies the information! This information doesn't consist of
the user saying "this is a delimiting use of callcc"; it is specified
by mentioning the delimiting, period (i.e., no continuation, shared or
otherwise, is grabbed at all). Hence, the ability of the user to
specify this information gives her a useful programming paradigm. She
hasn't lost anything however: she can continue to use callcc (or C or
F) _only_ and never bother about P at all. Furthermore, delimiting
costs nothing: it does lessen the cost of the control reifiers used
within it.
To be complete, b) is easily recognizable in a P world using a
cleaned-up but equivalent version of callcc, C (not the language!), or
an enhanced version, F. This isn't terribly interesting so I won't go
into it.
Re the positioning of P in tree-map: it appears to make sense to use
it at the start of a debug code-run. I.e., at the point where one
receives the result, or failing which, debug information. (That's
what "prompts" (albeit non-first-class) _are_ in the realworld (tm)
anyway.) However, it might appear I'm using too many textual P's;
this can be easily abstracted away, by putting them into the tree-map
code itself:
(define tree-map
(lambda (filter tree)
;-
(P (let ... (cond ...
;-
[(atom? tree)
... (F (lambda (context)
(list 'not-yet tree
;----------------------------
(lambda (debug-insert)
(P (context debug-insert)))))) ...]
;----------------------------
...)))))
Sure, this clouds the fact that each debug-run is run inside a prompt,
but retrieves Rick's callcc-based debugging style.
Going to things other than efficiency, note that I've made no claim
about the second piece of code being shorter (I'm not aiming for APL-
or C-like oneliners :-]). It may well be, but that's not a priority.
The presence of a delimiter/prompt (orthogonal from a
continuation-generator like callcc or F) is IMHO a better gain than
either conciseness or even efficiency alone would be.
Of course, the code could be (as has already been) written using only
callcc or F, but P abstracts away a convoluted style of delimiting,
not unlike the way callcc abstracts away the convoluted style of
passing continuations as arguments in the non-callcc version.
--dorai
--
------------------------------------------------------------------------------
It may be that the gulfs will wash us down;
It may be we shall touch the Happy Isles.
------------------------------------------------------------------------------
------------------------------
End of Scheme Digest
********************
∂19-Mar-90 0012 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #331
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 19 Mar 90 00:12:14 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA17659; Mon, 19 Mar 90 03:11:27 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Mon, 19 Mar 90 03:10:42 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa17450;
19 Mar 90 3:04 EST
Message-Id: <DIGEST.184.900319.024012.13@MC.LCS.MIT.EDU>
Date: 19 Mar 90 02:40:12 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #331
Scheme Digest #331 19 Mar 90 02:40:12 EST
Today's Topics:
Where can I Get Scheme-in-LISP?
----------------------------------------------------------------------
Message-ID: <5880@brazos.Rice.edu>
Date: 19 Mar 90 07:04:53 GMT
From: Dorai Sitaram <datura!dorai@rice.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: Where can I Get Scheme-in-LISP?
In article <22343@super.ORG> pcolsen@super.UUCP (Peter C Olsen) writes:
>
>I'm looking for an implementation of Scheme written in Common Lisp.
>
>I've recently managed to ``cumshaw'' two ``surplus'' Symbolics Lisp
>machines where I work and I much prefer working in Scheme to working in
>Common Lisp. Does anyone know where I can get a Scheme interpreter written
>in CL to run on them?
>
>Thanks!
how: anonymous ftp
where: rice.edu
file: public/scheme88.sh
--dorai
--
------------------------------------------------------------------------------
It may be that the gulfs will wash us down;
It may be we shall touch the Happy Isles.
------------------------------------------------------------------------------
------------------------------
End of Scheme Digest
********************
∂19-Mar-90 1355 @zurich.ai.mit.edu,@mc.lcs.mit.edu:dfried@iuvax.cs.indiana.edu lexical list
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 19 Mar 90 13:55:02 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA27876; Mon, 19 Mar 90 16:51:34 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Mon, 19 Mar 90 16:50:43 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa21676;
19 Mar 90 16:44 EST
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 19 Mar 90 16:44:36 EST
Received: from [129.79.254.192] by mintaka.lcs.mit.edu id aa21592;
19 Mar 90 16:43 EST
Received: by iuvax.cs.indiana.edu
Date: Mon, 19 Mar 90 16:42:45 -0500
From: Dan Friedman <dfried@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: lexical list
Message-Id: <9003191643.aa21592@mintaka.lcs.mit.edu>
if `(,+) expands to (list +), does
(let ((list (lambda args (write "hello"))))
`(,+))
also write "hello"?
Is this a bug or a feature?
.. Dan
∂19-Mar-90 1523 @zurich.ai.mit.edu,@mc.lcs.mit.edu,@life.ai.mit.edu:jar@zurich.ai.mit.edu lexical list
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 19 Mar 90 15:23:41 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA29396; Mon, 19 Mar 90 18:19:35 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Mon, 19 Mar 90 18:18:43 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa25362;
19 Mar 90 18:15 EST
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 19 Mar 90 18:16:12 EST
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa25158;
19 Mar 90 18:10 EST
Received: from zurich.ai.mit.edu ([18.43.0.158]) by life.ai.mit.edu (4.0/AI-4.10) id AA29256; Mon, 19 Mar 90 18:09:52 EST
Received: from localhost by zurich.ai.mit.edu; Mon, 19 Mar 90 18:09:19 est
Date: Mon, 19 Mar 90 18:09:19 est
From: Jonathan Rees <jar@zurich.ai.mit.edu>
Message-Id: <9003192309.AA10713@zurich.ai.mit.edu>
To: dfried@iuvax.cs.indiana.edu
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Dan Friedman's message of Mon, 19 Mar 90 16:42:45 -0500 <9003191643.aa21592@mintaka.lcs.mit.edu>
Subject: lexical list
Date: Mon, 19 Mar 90 16:42:45 -0500
From: Dan Friedman <dfried@iuvax.cs.indiana.edu>
if `(,+) expands to (list +), does
(let ((list (lambda args (write "hello"))))
`(,+))
also write "hello"?
Depends on whether you have hygienic macro expansion or not. If so,
you get a list with a procedure in it. If not, you get output.
Is this a bug or a feature?
... Dan
Depends on whether you think hygienic expansion is a good idea or not.
If so, getting output is a bug. If not, it's a feature.
∂19-Mar-90 1620 @zurich.ai.mit.edu,@mc.lcs.mit.edu:Pavel_Curtis.PARC@xerox.com Re: lexical list
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 19 Mar 90 16:19:57 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA00507; Mon, 19 Mar 90 19:17:41 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Mon, 19 Mar 90 19:16:43 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa27561;
19 Mar 90 19:11 EST
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 19 Mar 90 19:11:54 EST
Received: from Xerox.COM by mintaka.lcs.mit.edu id aa27218; 19 Mar 90 19:02 EST
Received: from Aurora.ms by ArpaGateway.ms ; 19 MAR 90 14:43:49 PST
Sender: Pavel_Curtis.PARC@xerox.com
Date: 19 Mar 90 14:33:13 PST (Monday)
Subject: Re: lexical list
From: Pavel_Curtis.PARC@xerox.com
To: dfried@iuvax.cs.indiana.edu
Cc: rrrs-authors@mc.lcs.mit.edu
Message-Id: <900319-144349-1501@Xerox>
From: Dan Friedman <dfried@iuvax.cs.indiana.edu>
Subject: lexical list
Date: Mon, 19 Mar 90 16:42:45 -0500
if `(,+) expands to (list +), does
(let ((list (lambda args (write "hello"))))
`(,+))
also write "hello"?
Is this a bug or a feature?
.. Dan
Since `(,+) is, more-or-less, required to read as (quasiquote ((unquote
+))), the real question is whether or not the expansion of the
QUASIQUOTE macro should leave LIST free in its expansion. I believe
that it should not and, further, that the various proposals being
discussed by the macros subcommittee would handle this just fine,
allowing the expansion to use LIST without getting that reference
captured.
A more interesting question, to my mind, is the value of the following
expression:
(let ((quote car))
'(a b))
I believe that the value of this expression should be the list (A B),
whereas the value of the expression
(let ((quote car))
(quote (a b)))
should (clearly?) be the symbol A. That is, in the language of the
now-passe syntactic closures proposal, the syntax '<datum> should be
parsed by the language processor as a syntactic closure of the
expression (quote <datum>) in the initial syntactic environment.
Of course, a similar story should hold for the expression `<datum>.
There is room for disagreement about the "," and ",@" constructions,
depending upon your view of auxiliary syntactic keywords, like ELSE and
=>.
Once one says that this is true, though, there remains the question of
what the READ procedure does with such constructions. Recall that
language processors need not use READ for their scanning and parsing...
Pavel
∂20-Mar-90 0643 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #332
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 20 Mar 90 06:43:44 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA07587; Tue, 20 Mar 90 09:38:48 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Tue, 20 Mar 90 03:47:28 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa17167;
20 Mar 90 3:15 EST
Message-Id: <DIGEST.184.900320.022527.19@MC.LCS.MIT.EDU>
Date: 20 Mar 90 02:25:26 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #332
Scheme Digest #332 20 Mar 90 02:25:26 EST
Today's Topics:
Case statements in sane languages (2 messages)
Type recovery payoff
----------------------------------------------------------------------
Message-ID: <9003191549.AA01608@sn1987a.compass.com>
Date: 19 Mar 90 15:49:40 GMT
From: Dale Worley <Compass.COM!worley@ucbvax.berkeley.edu>
To: scheme@mc.lcs.mit.edu
Subject: Case statements in sane languages
From: sanders@sanders.austin.ibm.com (Tony Sanders)
How do you do this in ADA?
switch(n) {
case 0:
count++;
case 1:
ocount++;
case 2:
printf("%d %d\n",count,ocount);
break;
default:
printf("unknown n\n");
break;
}
See how I left out the breaks on purpose.
In ADA you wouldn't be able to do this without duplicating either the
case-expression (they aren't always simple numbers) or the statements.
In this case, duplicating the statements wouldn't be hard enough to
worry about. If the bodies of the cases were large enough to make it
hard, you can write a local procedure, and just call it from several
cases. (Since Ada has nested procedures, you can write a procedure
that has access to local variables.)
The 11th commandment: "Thou shalt use lint"
In Ada (or any sane language), "Lint" is called "the compiler".
Dale Worley Compass, Inc. worley@compass.com
--
Why are you RUNNING? Cerebus just wants to KILL you a little...
------------------------------
Message-ID: <1925@mit-amt.MEDIA.MIT.EDU>
Date: 19 Mar 90 19:38:50 GMT
From: "Mario O. Bourgoin" <mob@media-lab.media.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: Case statements in sane languages
I feel I must interject a some Scheme code in this otherwise C-based
discussion cross-posted to comp.lang.scheme. In Scheme, there's a
control construct called CASE which is much like C's SWITCH except
that doesn't allow the clauses to be cascaded but it does allow
multiple constants per clause. It's easy to imagine a CASE-EVERY (in
the spirit of ZETALISP's COND-EVERY) very similar to CASE but that
evaluates every clause whose constant part includes the key. The
resulting structure passes control more explicitly than its C
equivalent, and yet remains simple enough to encourage programmers to
use it. For example:
(case-every (0
(1+ count))
((0 1)
(1+ ocount))
((0 1 2)
(writeln count ocount))
(else
(writeln "unknown n")))
--Mario
------------------------------
Message-ID: <9003191802.aa24822@mintaka.lcs.mit.edu>
Date: Mon, 19 Mar 90 18:00:06 EST
From: Olin Shivers <shivers@a.gp.cs.cmu.edu>
To: Scheme@mintaka.lcs.mit.edu
CC: daniel@mojave.stanford.edu
Subject: Type recovery payoff
Date: Fri, 16 Mar 90 09:11:08 PST
From: Daniel Weise <daniel@mojave.stanford.edu>
I've got a CMU tech report that shows how to do this analysis. ...
I have not, however, done large tests, as in: hook
the thing into a real compiler, compile some massive chunk of real
code, and measure the speedup over stupidly-typechecked code (or
the slowdown from dangerous code). So just how much type-recovery
analysis buys you has yet to be settled.
Isn't this the sort of analysis Steenkiste did and reported in LFP 86
and his thesis? He counted the speed with and without type safety, so
his work would be an upper bound on what type analysis could save.
Yep. Steenkiste ported the PSL compiler to the MIPS-X. He did a paranoid
backend that did full run-time type checking on all primitive operations --
CARS, CDRS, vector references, arithmetic, everything -- and he did a reckless
backend that did no type checking at all. He ran about 11,500 lines of Lisp
code through the two backends, and compared the run times of the result
executables (it's table 3-2 in his dissertation).
Full type checking added 25% to the execution time of the programs.
This sort of tells you that the payoff of compile-time analysis, which is
necessarily a conservative approximation, is bounded by that 25%.
Well, maybe. You have to take that number with a real grain of salt. I would
be wary of treating this number as anything more than a rough indicator.
Steenkiste's work is amazingly thorough and detailed, but the tiny details of
the processor architecture, compiler technology, data representations, and
program application all interact in pretty strong ways.
For example, Steenkiste's benchmark suite does no floating point computation,
and his generic arithmetic operations are tuned for the integer case. Even
his fully-checked code did not have to deal with type-checking calls to make
sure you are calling a real procedure -- which is critical in the single value
space of Scheme. There are several other details that could bias that 25%
number up or down, depending on details of the specific implementation.
Still, I walk away from his dissertation with the conclusion that there
is something there for compile-time analysis to pick up.
-Olin
------------------------------
End of Scheme Digest
********************
∂20-Mar-90 0828 @zurich.ai.mit.edu,@mc.lcs.mit.edu,@life.ai.mit.edu:markf@zurich.ai.mit.edu Re: lexical list
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 20 Mar 90 08:27:53 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA09676; Tue, 20 Mar 90 11:24:33 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Tue, 20 Mar 90 11:23:47 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa06294;
20 Mar 90 11:21 EST
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 20 Mar 90 11:16:42 EST
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa05837;
20 Mar 90 11:11 EST
Received: from zurich.ai.mit.edu ([18.43.0.244]) by life.ai.mit.edu (4.0/AI-4.10) id AA09483; Tue, 20 Mar 90 11:11:46 EST
Received: from localhost by zurich.ai.mit.edu; Tue, 20 Mar 90 11:11:10 est
Message-Id: <9003201611.AA02776@zurich.ai.mit.edu>
To: Pavel_Curtis.PARC@xerox.com
Cc: rrrs-authors@mc.lcs.mit.edu
Subject: Re: lexical list
In-Reply-To: Your message of 19 Mar 90 14:33:13 PST (Monday) .
<900319-144349-1501@Xerox>
Reply-To: markf@zurich.ai.mit.edu
Date: Tue, 20 Mar 90 11:11:03 EST
From: markf@zurich.ai.mit.edu
From: Pavel_Curtis.PARC@xerox.com
To: dfried@iuvax.cs.indiana.edu
Cc: rrrs-authors@mc.lcs.mit.edu
Message-Id: <900319-144349-1501@Xerox>
From: Dan Friedman <dfried@iuvax.cs.indiana.edu>
Subject: lexical list
Date: Mon, 19 Mar 90 16:42:45 -0500
if `(,+) expands to (list +), does
(let ((list (lambda args (write "hello"))))
`(,+))
also write "hello"?
Is this a bug or a feature?
.. Dan
Since `(,+) is, more-or-less, required to read as (quasiquote ((unquote
+))), the real question is whether or not the expansion of the
QUASIQUOTE macro should leave LIST free in its expansion. I believe
that it should not and, further, that the various proposals being
discussed by the macros subcommittee would handle this just fine,
allowing the expansion to use LIST without getting that reference
captured.
According to my understanding of r4rs and the ieee standard,
quasiquotations are syntax for constructing list and vectors. They are
not macros and the expansion of '(,+) into (list +) is really only
conceptual. Therefore, an implementation which treats quasiquote as a
macro must be hygenic.
A more interesting question, to my mind, is the value of the following
expression:
(let ((quote car))
'(a b))
I believe that the value of this expression should be the list (A B),
whereas the value of the expression
(let ((quote car))
(quote (a b)))
should (clearly?) be the symbol A. That is, in the language of the
now-passe syntactic closures proposal, the syntax '<datum> should be
parsed by the language processor as a syntactic closure of the
expression (quote <datum>) in the initial syntactic environment.
Again, according to the standards, quote is syntax for creating
constants. If you treat it as a macro it must be hygenic. The
standards also state that '<datum> is the same as (quote <datum>).
Of course, a similar story should hold for the expression `<datum>.
There is room for disagreement about the "," and ",@" constructions,
depending upon your view of auxiliary syntactic keywords, like ELSE and
=>.
Once one says that this is true, though, there remains the question of
What the READ procedure does with such constructions. Recall that
language processors need not use READ for their scanning and parsing...
I'm not sure that READ is really relevant to the issues.
Excuse me if Pavel's argument is about what he would like the
semantics of these expressions to be. My comments were on what I think
the semantics currently are.
-Mark
∂20-Mar-90 1207 @zurich.ai.mit.edu,@mc.lcs.mit.edu:Pavel_Curtis.PARC@xerox.com Re: lexical list
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 20 Mar 90 12:07:06 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA13505; Tue, 20 Mar 90 15:04:34 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Tue, 20 Mar 90 15:03:44 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa00571;
20 Mar 90 14:51 EST
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 20 Mar 90 14:51:52 EST
Received: from Xerox.COM by mintaka.lcs.mit.edu id aa15870; 20 Mar 90 14:26 EST
Received: from Aurora.ms by ArpaGateway.ms ; 20 MAR 90 11:12:34 PST
Sender: Pavel_Curtis.PARC@xerox.com
Date: 20 Mar 90 11:08:48 PST (Tuesday)
Subject: Re: lexical list
From: Pavel_Curtis.PARC@xerox.com
To: markf@zurich.ai.mit.edu
Cc: rrrs-authors@mc.lcs.mit.edu
Message-Id: <900320-111234-1384@Xerox>
I think Mark missed the point of my note about the '<datum> syntax. He
may have been helped in that by the incorrectness of my example, pointed
out by Kent Pitman. Let me try again with a fixed example.
I believe that the following expression should evaluate to the list (+ 2
3):
(let ((quote -))
'(+ 2 3))
but that, of course, the following expression should evaluate to the
integer -5:
(let ((quote -))
(quote (+ 2 3)))
These expressions are not legal under either the IEEE standard or R4RS
because they involve the binding of a reserved word, QUOTE. The
question is only what they should mean once the prohibition against
reusing those words is removed, once we have macros.
R4RS and the standard state now that the expression '<datum> is
equivalent to the expression (quote <datum>). This is unambiguous now
but becomes ambiguous when the reserved words become unreserved. I am
proposing that we plan on resolving that ambiguity by stating that the
meaning of the expression '<datum> is the same as the interpretation of
the expression (quote <datum>) in the initial Scheme syntactic
environment.
Pavel
∂20-Mar-90 1259 markf@zurich.ai.mit.edu Re: lexical list
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 20 Mar 90 12:59:27 PST
Received: from zurich.ai.mit.edu ([18.43.0.244]) by life.ai.mit.edu (4.0/AI-4.10) id AA14532; Tue, 20 Mar 90 15:56:07 EST
Received: from localhost by zurich.ai.mit.edu; Tue, 20 Mar 90 15:55:11 est
Message-Id: <9003202055.AA17019@zurich.ai.mit.edu>
To: rrrs-authors@zurich.ai.mit.edu
Subject: Re: lexical list
In-Reply-To: Your message of 20 Mar 90 11:08:48 PST (Tuesday) .
<900320-111234-1384@Xerox>
Reply-To: markf@zurich.ai.mit.edu
Date: Tue, 20 Mar 90 15:55:07 EST
From: markf@zurich.ai.mit.edu
>> I think Mark missed the point of my note about the '<datum> syntax.
Yes I did misunderstand. I didn't realize that the reserved words will
become unreserved. Is this the current consensus? Is the plan then
that "syntax" in the current reports will become "standard syntax"
when macros are added? What will be the status of top-level syntax
definitions? The macro committee draft that I saw says that
define-syntax extends the syntactic environment. I didn't see any
provision for assignment to a syntactic keyword.
I think that may point with respect to quasiquote still
stands though.
-Mark
∂20-Mar-90 1318 jmiller@macadamia.cs.brandeis.edu lexical list
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 20 Mar 90 13:18:17 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA14868; Tue, 20 Mar 90 16:16:08 EST
Received: from chaos.cs.brandeis.edu (chaos.cs.brandeis.edu) by zurich.ai.mit.edu; Tue, 20 Mar 90 16:14:50 est
Received: from macadamia.cs.brandeis.edu by chaos.cs.brandeis.edu Tue, 20 Mar 90 16:14:48 -0500
Message-Id: <9003202114.AA01025@chaos.cs.brandeis.edu>
Received: by macadamia.cs.brandeis.edu; Tue, 20 Mar 90 16:06:16 -0500
Date: Tue, 20 Mar 90 16:06:16 -0500
From: Jim Miller <jmiller@macadamia.cs.brandeis.edu>
To: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: markf@zurich.ai.mit.edu's message of Tue, 20 Mar 90 15:55:07 EST <9003202055.AA17019@zurich.ai.mit.edu>
Subject: lexical list
Reply-To: JMiller@chaos.cs.brandeis.edu.cs.brandeis.edu
There is definitely NOT a consensus on this point. This needs public
(face to face) discussion. I urge Pavel to prepare a 5 minute
presentation on this particular issue for the next RnRS authors
meeting, whenever and wherever that may be.
--Jim
∂20-Mar-90 1319 @zurich.ai.mit.edu,@mc.lcs.mit.edu,@life.ai.mit.edu:jinx@zurich.ai.mit.edu lexical list
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 20 Mar 90 13:19:40 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA14883; Tue, 20 Mar 90 16:16:29 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Tue, 20 Mar 90 16:15:09 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa04013;
20 Mar 90 15:53 EST
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 20 Mar 90 15:53:19 EST
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa03878;
20 Mar 90 15:50 EST
Received: from zurich.ai.mit.edu ([18.43.0.171]) by life.ai.mit.edu (4.0/AI-4.10) id AA14399; Tue, 20 Mar 90 15:50:33 EST
Received: from localhost by zurich.ai.mit.edu; Tue, 20 Mar 90 15:50:02 est
Date: Tue, 20 Mar 90 15:50:02 est
From: "Guillermo J. Rozas" <jinx@zurich.ai.mit.edu>
Message-Id: <9003202050.AA16541@zurich.ai.mit.edu>
To: Pavel_Curtis.PARC@xerox.com
Cc: markf@zurich.ai.mit.edu, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Pavel_Curtis.PARC@xerox.com's message of 20 Mar 90 11:08:48 PST (Tuesday) <900320-111234-1384@Xerox>
Subject: lexical list
Reply-To: jinx@zurich.ai.mit.edu
R4RS and the standard state now that the expression '<datum> is
equivalent to the expression (quote <datum>). This is unambiguous now
but becomes ambiguous when the reserved words become unreserved. I am
proposing that we plan on resolving that ambiguity by stating that the
meaning of the expression '<datum> is the same as the interpretation of
the expression (quote <datum>) in the initial Scheme syntactic
environment.
I don't like this at all.
I think that the traditional meaning, that is, the character-level
parser (ie. READ) expands '<anything> into (QUOTE <anything>) and the
current syntactic (or otherwise) binding of QUOTE is used, is a simpler
model and much better. I'd rather not intertwine character-level
syntax with s-expression syntax as deeply as you would like.
It's also the case that if I rebind QUOTE, it's precisely to obtain a
new version (that perhaps interns constants), even when I use the #\'
syntax.
I don't think that this is inconsistent with requiring `(,x) to always
be a list (unless QUASIQUOTE is shadowed), since the simple model for
the parser still holds. The big mess is hidden inside QUASIQUOTE, in
the syntax resolver, not in the character-level parser.
∂20-Mar-90 1324 dyb@iuvax.cs.indiana.edu Re: lexical list
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 20 Mar 90 13:24:05 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA14972; Tue, 20 Mar 90 16:20:38 EST
Received: from iuvax.cs.indiana.edu (iuvax.cs.indiana.edu) by zurich.ai.mit.edu; Tue, 20 Mar 90 16:19:45 est
Message-Id: <9003202119.AA18092@zurich.ai.mit.edu>
Received: by iuvax.cs.indiana.edu
Date: Tue, 20 Mar 90 16:19:16 -0500
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
To: markf@zurich.ai.mit.edu
Subject: Re: lexical list
Cc: rrrs-authors@zurich.ai.mit.edu
> >> I think Mark missed the point of my note about the '<datum> syntax.
>
> Yes I did misunderstand. I didn't realize that the reserved words will
> become unreserved. Is this the current consensus? Is the plan then
> that "syntax" in the current reports will become "standard syntax"
> when macros are added? What will be the status of top-level syntax
> definitions? The macro committee draft that I saw says that
> define-syntax extends the syntactic environment. I didn't see any
> provision for assignment to a syntactic keyword.
The macro committee is still working out some major issues, and the
only draft so far is very rough and is likely to change substantially
before it goes out. So, don't make any assumptions based on what you
read there.
To answer the particular question, I believe that it is the concensus
of the macro committee that it should be possible to redefine and
shadow syntactic keywords. For example, it should be possible to
write:
(define-syntax quote ???)
or:
(let ([quote -]) ???)
There has not been any discussion among the macro committee that I am
aware of regarding the status of "'", "`", ",", and ",@", prior to the
current discussion in this newsgroup. For what it's worth, I don't
like with Pavel's suggestion that "'x" be treated differently "(quote
x)"; this would make the use of "read" as a front end to the compiler
impossible, unless we change "read" in some strange way, and it means
that I can't redefine "quote" and use the handy "'" mark to refer to my
own version of "quote". It also seems strange to provide a back-door
way to insert top-level "quote" into a program where no such mechanism
is provided for other top-level syntax keywords.
Kent
∂20-Mar-90 1404 cph@zurich.ai.mit.edu lexical list
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 20 Mar 90 14:04:37 PST
Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.0/AI-4.10) id AA15698; Tue, 20 Mar 90 17:00:37 EST
Received: from localhost by zurich.ai.mit.edu; Tue, 20 Mar 90 17:00:00 est
Date: Tue, 20 Mar 90 17:00:00 est
From: cph@zurich.ai.mit.edu (Chris Hanson)
Message-Id: <9003202200.AA05181@zurich.ai.mit.edu>
To: dyb@iuvax.cs.indiana.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: R. Kent Dybvig's message of Tue, 20 Mar 90 16:19:16 -0500
Subject: lexical list
Date: Tue, 20 Mar 90 16:19:16 -0500
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
There has not been any discussion among the macro committee that I am
aware of regarding the status of "'", "`", ",", and ",@", prior to the
current discussion in this newsgroup. For what it's worth, I don't
like with Pavel's suggestion that "'x" be treated differently "(quote
x)"; this would make the use of "read" as a front end to the compiler
impossible, unless we change "read" in some strange way, and it means
that I can't redefine "quote" and use the handy "'" mark to refer to my
own version of "quote". It also seems strange to provide a back-door
way to insert top-level "quote" into a program where no such mechanism
is provided for other top-level syntax keywords.
I agree with both Kent and Jinx on this issue: the reader's "'" and
"`" syntax should be equivalent to the "quote" and "quasiquote"
expressions. If we permit "quote" or "quasiquote" to be redefined,
then the reader syntax should be captured by this redefinition exactly
as the "quote" and "quasiquote" expressions are.
∂20-Mar-90 1519 Pavel_Curtis.PARC@xerox.com Re: lexical list
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 20 Mar 90 15:19:10 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA17201; Tue, 20 Mar 90 18:13:54 EST
Received: from Xerox.COM (xerox.com) by zurich.ai.mit.edu; Tue, 20 Mar 90 18:13:08 est
Received: from Aurora.ms by ArpaGateway.ms ; 20 MAR 90 15:09:24 PST
Sender: "Pavel_Curtis.PARC"@xerox.com
Date: 20 Mar 90 15:08:52 PST (Tuesday)
Subject: Re: lexical list
From: "Pavel_Curtis.PARC"@xerox.com
To: rrrs-authors@zurich.ai.mit.edu
Message-Id: <900320-150924-2300@Xerox>
Interesting. People want their macros to be hygenic but not their
reader macros. Is this because, unlike normal macros, the expansions of
the reader macros have been specified? If so, then I guess I could
agree with this point of view. On the other hand, it would also be
possible to respecify the meanings of the reader macros without
mentioning their exact expansions, just as we do for normal derived
syntax. Is there any support for such a position?
Pavel
∂21-Mar-90 0024 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #333
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Mar 90 00:24:08 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA24342; Wed, 21 Mar 90 03:16:42 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Wed, 21 Mar 90 03:15:50 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa04597;
21 Mar 90 2:49 EST
Message-Id: <DIGEST.184.900321.021031.25@MC.LCS.MIT.EDU>
Date: 21 Mar 90 02:10:31 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #333
Scheme Digest #333 21 Mar 90 02:10:31 EST
Today's Topics:
Case statements: Error in my reply.
Where can I Get Scheme-in-LISP?
----------------------------------------------------------------------
Message-ID: <1936@mit-amt.MEDIA.MIT.EDU>
Date: 20 Mar 90 16:02:59 GMT
From: "Mario O. Bourgoin" <mob@media-lab.media.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Case statements: Error in my reply.
I apologize for having made an error in my reply's example. I left
out the expression that evaluates to the selection key. Here is the
correct code:
(case-every n
(0
(1+ count))
((0 1)
(1+ ocount))
((0 1 2)
(writeln count ocount))
(else
(writeln "unknown n")))
--Mario
------------------------------
Message-ID: <5915@brazos.Rice.edu>
Date: 20 Mar 90 17:14:27 GMT
From: Dorai Sitaram <helma!dorai@rice.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: Where can I Get Scheme-in-LISP?
In article <5880@brazos.Rice.edu> dorai@datura.rice.edu (Dorai Sitaram) writes:
>In article <22343@super.ORG> pcolsen@super.UUCP (Peter C Olsen) writes:
>>
>>I'm looking for an implementation of Scheme written in Common Lisp.
>
>how: anonymous ftp
>where: rice.edu
>file: public/scheme88.sh
Goof correction time:
The where: field should read titan.rice.edu .
↑↑↑↑↑
(The .sh extension doesn't mean anything. It's just a shar file.)
--dorai
--
------------------------------------------------------------------------------
It may be that the gulfs will wash us down;
It may be we shall touch the Happy Isles.
------------------------------------------------------------------------------
------------------------------
End of Scheme Digest
********************
∂21-Mar-90 1714 @zurich.ai.mit.edu,@mc.lcs.mit.edu:Pavel_Curtis.PARC@xerox.com Scheme Modules paper available
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Mar 90 17:14:26 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA07854; Wed, 21 Mar 90 20:10:31 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Wed, 21 Mar 90 20:09:01 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa18613;
21 Mar 90 19:47 EST
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 21 Mar 90 19:47:36 EST
Received: from Xerox.COM by mintaka.lcs.mit.edu id aa18453; 21 Mar 90 19:41 EST
Received: from Aurora.ms by ArpaGateway.ms ; 21 MAR 90 16:31:54 PST
Sender: Pavel_Curtis.PARC@xerox.com
Date: 21 Mar 90 16:31:22 PST (Wednesday)
Subject: Scheme Modules paper available
From: Pavel_Curtis.PARC@xerox.com
To: rrrs-authors@mc.lcs.mit.edu, scheme@mc.lcs.mit.edu
Cc: Pavel.PARC@xerox.com, rauen@brokaw.lcs.mit.edu
Reply-To: Pavel.PARC@xerox.com, rauen@brokaw.lcs.mit.edu
Message-Id: <900321-163154-6092@Xerox>
Jim Rauen and I have recently completed the final version of our paper
on modules in Scheme for the 1990 Lisp and Functional Programming
Conference.
The DVI file for the paper is now available for anonymous FTP at the
host Arisia.Xerox.Com in the file pub/SchemeModules.dvi. Feel free.
If you cannot use FTP, and you really don't want to wait until the
conference proceedings are available, then send me mail and I'll add you
to my list of folks to be sent copies of the Xerox technical report
version of the paper (identical but for the formatting), ready in about
a week or so.
Thanks for your interest,
Pavel Curtis
Pavel@Xerox.Com
∂22-Mar-90 0113 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #334
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Mar 90 01:13:22 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA13655; Thu, 22 Mar 90 04:07:30 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Thu, 22 Mar 90 04:05:59 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa07718;
22 Mar 90 3:49 EST
Message-Id: <DIGEST.184.900322.031035.31@MC.LCS.MIT.EDU>
Date: 22 Mar 90 03:10:34 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #334
Scheme Digest #334 22 Mar 90 03:10:34 EST
Today's Topics:
Bug in MIT-Scheme
structure-sharing continuations v I-class P (was Re: call/cc) and Re: Where can I Get Scheme-in-LISP? (2 messages)
Scheme Modules paper available
programming with user-level continuations
----------------------------------------------------------------------
Message-ID: <2063@laura.UUCP>
Date: 21 Mar 90 13:46:55 GMT
From: Holger Muenx <mcsun!unido!laura!heike.informatik.uni-dortmund.de!muenx@uunet.uu.net>
To: scheme@mc.lcs.mit.edu
Subject: Bug in MIT-Scheme
I think I found a small bug in MIT-Scheme V7.0. Look at the following
transcript:
1 ]=> (string->symbol "loadConst")
;Value: loadConst
The resulting symbol consists of upcase und lowercase letters. It's a bit
disturbing if you look at these lines:
1 ]=> (eq? (string->symbol "loadConst") 'loadConst)
;Value: ()
1 ]=> (eq? (string->symbol "loadConst") 'loadconst)
;Value: ()
Any idea?
-Holger
=============================================================================
Holger Muenx muenx@heike.informatik.uni-dortmund.de
IRB, UniDo
4600 Dortmund "My opinions are shareware. Send $10
West-Germany if you like them."
------------------------------
Message-ID: <5944@brazos.Rice.edu>
Date: 21 Mar 90 17:12:56 GMT
From: Dorai Sitaram <helma!dorai@rice.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: structure-sharing continuations v I-class P (was Re: call/cc) and Re: Where can I Get Scheme-in-LISP?
In article <5855@brazos.Rice.edu> dorai@hedera.rice.edu (Dorai Sitaram) writes:
>$The efficiency issue is not clear. It all depends on the exact
>$implementation of call-with-current-continuation. If the
>$continuations share structure (as they do in some implementationts),
>$the solution based on F is no more time or space efficient.
>$
>$Note also that your version is shorter because you have moved some of
>$the code to the use point (by inserting "prompts").
>
>Hi, I'll take the liberty of answering you on the net too, for
>purposes of clarification. This will not prevent the following from
While I took the questionable liberty of quoting the $'d email above,
I neglected to say who it was from. It's from Guillermo J. Rozas,
MIT. My apologies to Guillermo.
***
About Rice's Scheme88 which I earlier mentioned was available via
anonymous ftp: It derives from Indiana's Scheme84, and was written
predominantly by John Greiner (jg@..., currently at CMU) in Ibuki
CommonLisp. It is now mostly maintained by Steve Weeks (weeks@rice),
Rice. Questions may be directed to either of them. (I'm sure they
won't mind :-].)
Once again, the ftp address is titan.rice.edu, _not_ rice.edu, and the
file to get is public/scheme88.sh .
--dorai
--
------------------------------------------------------------------------------
It may be that the gulfs will wash us down;
It may be we shall touch the Happy Isles.
------------------------------------------------------------------------------
------------------------------
Message-ID: <8536@pt.cs.cmu.edu>
Date: 21 Mar 90 20:52:21 GMT
From: John Greiner <gs2.sp.cs.cmu.edu!jdg@pt.cs.cmu.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: structure-sharing continuations v I-class P (was Re: call/cc) and Re: Where can I Get Scheme-in-LISP?
In article <5944@brazos.Rice.edu> dorai@helma.rice.edu (Dorai Sitaram) writes:
>About Rice's Scheme88 which I earlier mentioned was available via
>anonymous ftp: It derives from Indiana's Scheme84, and was written
>predominantly by John Greiner (jg@..., currently at CMU) in Ibuki
>CommonLisp. It is now mostly maintained by Steve Weeks (weeks@rice),
>Rice. Questions may be directed to either of them. (I'm sure they
>won't mind :-].)
>
>Once again, the ftp address is titan.rice.edu, _not_ rice.edu, and the
>file to get is public/scheme88.sh .
>
>--dorai
That's jdg@cs.cmu.edu, dorai. Unfortunately, Scheme88 uses some IBUKI
CL specific functions. I'm in the slow process of figuring out what
changes are necessary in the code for some other dialects. If you have
any problems in porting it, I can tell you what needs to be changed
and why, but not necessarily to what.
BTW, Scheme88 is _almost_ R↑3S compatible.
jg
------------------------------
Message-ID: <900321-163154-6092@Xerox>
Date: 21 Mar 90 16:31:22 PST (Wednesday)
From: Pavel_Curtis.PARC@xerox.com
Reply-To: Pavel.PARC@xerox.com, rauen@brokaw.lcs.mit.edu
To: rrrs-authors@mc.lcs.mit.edu, scheme@mc.lcs.mit.edu
CC: Pavel.PARC@xerox.com, rauen@brokaw.lcs.mit.edu
Subject: Scheme Modules paper available
Jim Rauen and I have recently completed the final version of our paper
on modules in Scheme for the 1990 Lisp and Functional Programming
Conference.
The DVI file for the paper is now available for anonymous FTP at the
host Arisia.Xerox.Com in the file pub/SchemeModules.dvi. Feel free.
If you cannot use FTP, and you really don't want to wait until the
conference proceedings are available, then send me mail and I'll add you
to my list of folks to be sent copies of the Xerox technical report
version of the paper (identical but for the formatting), ready in about
a week or so.
Thanks for your interest,
Pavel Curtis
Pavel@Xerox.Com
------------------------------
Message-ID: <9003220542.AA25231@bronto.soar.cs.cmu.edu>
Date: Thu, 22 Mar 90 00:42:59 EST
From: Olin Shivers <shivers@bronto.soar.cs.cmu.edu>
To: Scheme@MINTAKA.LCS.MIT.EDU
Subject: programming with user-level continuations
Aamod Sane wrote:
I would also like examples/references on the Continuation
Passing style (just building of lambdas, not the call/cc variety).
I know of examples such as gcd of a list where you can escape
if a 1 is encountered without doing any computation, by building lambdas
and using them only if 1 is not found.
I think the Sutherland-Hodgmann polygon clipping algorithm is a lovely
example. Here is one I wrote in T in 1983 for part of an object-oriented
graphics system in T. The clipper itself is in GEN-POLYGON-CLIPPER.
The rest of the code is auxiliaries and clients. MAKE-CAMERA-CLIPPER
shows how to build up a pipeline of clippers.
Dialect/ideolect specifics:
fl+, fl-, and friends are T's floating-point specific math functions.
? means COND; := means SET or SET! in my personal ideolect.
I assume T is a constant bound to a true value and NIL is a constant
bound to the the empty list/false value. This code was written in
1983. There was no #T, or #F; () was the false value.
FOR is the UCI Lisp FOR macro, ported to T.
-Olin
===============================================================================
(herald planeint (env t (graphics points) (tlib hacks) (tutil for)))
;(require hacks (tlib hacks))
;(require points (graphics points))
;;; This file contains functions for doing operations on points and
;;; planes.
;;; plane-sign tells which side of a plane the point is on. It is negative
;;; if the pt is on the negative side, 0 if it is in the plane, and positive
;;; if the pt is on the positive side.
(define-integrable (plane-sign plane pt)
(fl+ (plane:d plane) (dot-prod plane pt)))
;;; crosses-plane? returns true <==> pt0 and pt1 are on opposite sides of
;;; the plane. (minus? (* (plane-sign plane pt0) (plane-sign plane pt1)))
(define (crosses-plane? plane pt0 pt1)
(fl> 0.0 (fl* (plane-sign plane pt0) (plane-sign plane pt1))))
;;; plane-intersect gives the point which is the intersection of plane and
;;; the line running through pt0 and pt1. If the plane is (P; d) and
;;; the points are A and B, the intersection parameter s is
;;; P.A - d
;;; s = -------
;;; P.(A-B)
(define (plane-intersect plane pt0 pt1)
(let ((delta (pt- pt1 pt0)))
(if (pt-zero? delta)
(error "plane-intersect: degenerate line segment (~s,~s)~%" pt0 pt1)
(let ((denom (fl- 0.0 (dot-prod plane delta))))
(if (fl= 0.0 denom)
(error "plane-intersect: line (~s,~s) is parallel to plane ~s~%"
pt0 pt1 plane)
(let ((s (fl/ (fl- (dot-prod plane pt0) (plane:d plane)) denom)))
(pt+ pt0 (pt* delta s))))))))
;;; gen-polygon-clipper takes a plane and a continuation as args. It
;;; returns a closure that, when called on successive points in a polygon,
;;; clips them against the plane and sends them on to the continuation.
;;; The end of the polygon is signalled by calling the clipper on T or nil.
;;; If the closure is called on T, the polygon is closed, i.e. the previous
;;; point is connected to the first point of the polygon. In either case,
;;; the terminal T/nil is passed along, in case the continuation is another
;;; clipping stage.
(define (gen-polygon-clipper plane cont)
(let ((first-pt nil) (pt0 nil))
(lambda (x)
(? ((eq? x t) ;x=t means time to close the polygon
(if (and first-pt (crosses-plane? plane pt0 first-pt))
(cont (plane-intersect plane pt0 first-pt)))
(set first-pt nil)
(cont t)) ;pass along the close signal
(x ;x is the next point in the polygon
(if (not first-pt) (set first-pt x)
(if (crosses-plane? plane pt0 x) ;edge crosses ==>
(cont (plane-intersect plane x pt0)))) ;output intersection
(set pt0 x)
(if (fl<= 0.0 (plane-sign plane pt0)) (cont pt0)))
(t ;null x means the stream is done, but do not close back to first-pt
(set first-pt nil)
(cont nil) ;pass along the close signal
)))))
(define (gen-polygon-splitter plane cont1 cont2)
(let ((first-pt nil) (pt0 nil))
(lambda (x)
(? ((eq? x t) ;x=t means time to close the split polys
(if (crosses-plane? plane pt0 first-pt)
(let ((i (plane-intersect plane pt0 first)))
(cont1 i)
(cont2 i)))
(set first-pt nil)
(cont1 t) ;pass along the close signal
(cont2 t))
(x
(if (null? first-pt) (set first-pt x)
(if (crosses-plane? plane pt0 x)
(let ((i (plane-intersect plane pt0 x)))
(cont1 i)
(cont2 i))))
(set pt0 x)
(let ((s (plane-sign plane pt0)))
(if (fl<= 0.0 s) (cont1 pt0))
(if (fl>= 0.0 s) (cont2 pt0))))
(t ;null x means the stream is done, but do not close back to first-pt
(set first-pt nil)
(cont1 nil) ;pass along the done signal
(cont2 nil)
)))))
(define (clip-polygon polygon plane)
(let ((pts (disclose-pts polygon))
(newpts nil))
(let ((clipper (gen-polygon-clipper plane (lambda (x) (push newpts x)))))
;;feed the points to the polygon clipper
(for (x in pts)
(do (clipper x)))
;;close the polygon
(clipper t)
;;return the polygon whose points are newpts
(polygon:new (reverse! (cdr newpts))))))
(define-integrable (make-camera-clipper top bot left right)
(let* ( (clipped-pts nil)
(clipper (gen-polygon-clipper top
(gen-polygon-clipper bot
(gen-polygon-clipper left
(gen-polygon-clipper right
(gen-polygon-clipper *hither-plane*
(gen-polygon-clipper *yon-plane*
(lambda (p)
(push clipped-pts p))))))))) )
(lambda (pts close?)
(:= clipped-pts nil)
(for (p in pts) (do (clipper p)))
(clipper close?)
(reverse! (cdr clipped-pts))) ))
------------------------------
End of Scheme Digest
********************
∂22-Mar-90 0939 rauen@brokaw.lcs.mit.edu Re: A module question
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Mar 90 09:39:33 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA18809; Thu, 22 Mar 90 12:37:15 EST
Received: from brokaw.LCS.MIT.EDU (brokaw.lcs.mit.edu) by zurich.ai.mit.edu; Thu, 22 Mar 90 12:36:33 est
Received: by brokaw.LCS.MIT.EDU
id AA21166; Thu, 22 Mar 90 12:36:50 EST
Date: Thu, 22 Mar 90 12:36:50 EST
From: rauen@brokaw.lcs.mit.edu (James R. Rauen)
Message-Id: <9003221736.AA21166@brokaw.LCS.MIT.EDU>
To: rrrs-authors@zurich.ai.mit.edu
Subject: Re: A module question
John Ramsdell:
> In the Curtis/Rauen module proposal, what do non definitions within
> modules mean? For example, what is printed by the following program?
>
>
> (interface a (value x))
> (interface b (value y))
> (module f ((exports a) (imports b) (open b))
> (define x 0)
> (set! x (+ x y)))
> (module g ((exports b) (imports a) (open a))
> (define y 0)
> (set! y (+ x y)))
> (display f#x)
> (display g#y)
First, modules are anonymous, and a reference to a shared item like
"f#x" above is made via the interface name. So the above program
should actually be:
(interface a (value x))
(interface b (value y))
(module ((exports a) (imports b) (open b))
(define x 0)
(set! x (+ x y)))
(module ((exports b) (imports a) (open a))
(define y 0)
(set! y (+ x y)))
(display a#x)
(display b#y)
Expressions and definitions inside a module are evaluated in order, in
the order that the modules appear in the program. Expressions in this
context are only useful for their side-effects. In the example, the
first assignment statement would be in error, because it makes a
reference to "y" before y is defined.
Your example program is equivalent to the following plain Scheme
expression:
(let ((a_x #!UNSPECIFIED) ; Shared variables, initially unbound
(b_y #!UNSPECIFIED)) ; .
(let () ; Translation of first module
(set! a_x 0) ; .
(set! a_x (+ a_x b_y))) ; .
(let () ; Translation of second module
(set! b_y 0) ; .
(set! b_y (+ a_x b_y))) ; .
(display a_x)
(display b_y))
By the way, I have been working on an implementation that translates
programs with modules into plain Scheme (like the translation above).
I'll send word out when it's ready.
Jim
∂22-Mar-90 1041 Pavel_Curtis.PARC@xerox.com Re: A module question
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Mar 90 10:41:43 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA19925; Thu, 22 Mar 90 13:37:04 EST
Received: from Xerox.COM (xerox.com) by zurich.ai.mit.edu; Thu, 22 Mar 90 13:35:52 est
Received: from Aurora.ms by ArpaGateway.ms ; 22 MAR 90 10:24:43 PST
Sender: "Pavel_Curtis.PARC"@xerox.com
Date: 22 Mar 90 10:23:43 PST (Thursday)
Subject: Re: A module question
From: "Pavel_Curtis.PARC"@xerox.com
To: ramsdell@linus.mitre.org
Cc: rrrs-authors@zurich.ai.mit.edu
Message-Id: <900322-102443-8255@Xerox>
Date: 22-Mar-90 6:28:19 PST
From: ramsdell%linus.mitre:ORG:Xerox
In the Curtis/Rauen module proposal, what do non definitions within
modules mean? For example, what is printed by the following
program?
(interface a (value x))
(interface b (value y))
(module f ((exports a) (imports b) (open b))
(define x 0)
(set! x (+ x y)))
(module g ((exports b) (imports a) (open a))
(define y 0)
(set! y (+ x y)))
(display f#x)
(display g#y)
I am amazed that we forgot to explain this in the paper. Sigh.
The answer is that the semantics are a generalization of the R4RS
semantics, in which global bindings are initialized to some unspecified
values, the DEFINEs are turned into SET!s, and the resulting program is
evaluated from top to bottom. Thus, in this case, the form
(set! x (+ x y))
would be in error, referencing an as-yet unassigned binding.
A note on your example, though: modules do not have names in our
proposal, so the "f" and "g" in your code shouldn't be there. The two
qualified names at the end should be a#x and b#y.
Changing the subject, I would like to start a discussion on this
module proposal by asking the following question.
Ignoring meta-modules, what do you think about the idea of
basing a module system on a simplification of the Mesa design?
In particular, is the notion that modules should not be first
class controversial?
In my opinion, modules should not be first class.
John
Our opinion on this matter appears in the paper, of course. We also
oppose first-class modules in the absence of strong typing since they
prevent any reasonable level of static checking of inter-module
references. As a corollary to that, they seem in conflict with the
(important, to us) notion of explicit, textually-distinct specifications
of the interfaces between modules.
Pavel
PS- I just got Jim's response to John's note. I'm sending this out
anyway just to have two wordings available of essentially the same
answer.
∂22-Mar-90 1713 ramsdell@linus.mitre.org A module question
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Mar 90 17:13:01 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA15165; Thu, 22 Mar 90 08:34:39 EST
Received: from linus.mitre.org (linus.mitre.org) by zurich.ai.mit.edu; Thu, 22 Mar 90 08:33:48 est
Received: from huxley.mitre.org by linus.mitre.org (5.61/RCF-4S)
id AA14014; Thu, 22 Mar 90 08:34:28 -0500
Posted-Date: Thu, 22 Mar 90 08:34:24 EST
Received: by huxley.mitre.org (5.61/RCF-4C)
id AA01233; Thu, 22 Mar 90 08:34:26 -0500
From: ramsdell@linus.mitre.org
Message-Id: <9003221334.AA01233@huxley.mitre.org>
To: rrrs-authors@zurich.ai.mit.edu
Cc: ramsdell@linus.mitre.org
Subject: A module question
Date: Thu, 22 Mar 90 08:34:24 EST
In the Curtis/Rauen module proposal, what do non definitions within
modules mean? For example, what is printed by the following program?
(interface a (value x))
(interface b (value y))
(module f ((exports a) (imports b) (open b))
(define x 0)
(set! x (+ x y)))
(module g ((exports b) (imports a) (open a))
(define y 0)
(set! y (+ x y)))
(display f#x)
(display g#y)
###########################################
Changing the subject, I would like to start a discussion on this
module proposal by asking the following question.
Ignoring meta-modules, what do you think about the idea of
basing a module system on a simplification of the Mesa design?
In particular, is the notion that modules should not be first
class controversial?
In my opinion, modules should not be first class.
John
∂23-Mar-90 0102 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #335
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Mar 90 01:02:13 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA02679; Fri, 23 Mar 90 03:59:12 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Fri, 23 Mar 90 03:58:23 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa08962;
23 Mar 90 3:40 EST
Message-Id: <DIGEST.184.900323.025538.36@MC.LCS.MIT.EDU>
Date: 23 Mar 90 02:55:38 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #335
Scheme Digest #335 23 Mar 90 02:55:38 EST
Today's Topics:
Bug in MIT-Scheme
Scheme for Amiga
Getting scheme-7.0
----------------------------------------------------------------------
Message-ID: <9003221201.AA11816@zurich.ai.mit.edu>
Date: Thu, 22 Mar 90 07:01:42 est
From: "Guillermo J. Rozas" <jinx@zurich.ai.mit.edu>
Reply-To: jinx@zurich.ai.mit.edu
To: mcsun!unido!laura!heike.informatik.uni-dortmund.de!muenx@uunet.uu.net
CC: scheme@mc.lcs.mit.edu
Subject: Bug in MIT-Scheme
Date: 21 Mar 90 13:46:55 GMT
From: Holger Muenx <mcsun!unido!laura!heike.informatik.uni-dortmund.de!muenx@uunet.uu.net>
I think I found a small bug in MIT-Scheme V7.0. Look at the following
transcript:
1 ]=> (string->symbol "loadConst")
;Value: loadConst
The resulting symbol consists of upcase und lowercase letters. It's a bit
disturbing if you look at these lines:
1 ]=> (eq? (string->symbol "loadConst") 'loadConst)
;Value: ()
1 ]=> (eq? (string->symbol "loadConst") 'loadconst)
;Value: ()
Any idea?
-Holger
The R3RS report, in the section for symbols (sectin 6.4) reads:
"The string->symbol procedure, however, can create symbols for which
this write/read invariance may not hold because their names contain
special characters of letters in the non-standard case."
Given that MIT Scheme uses lower case as the standard case, the print
name for symbol 'loadConst is "loadconst", and (string->symbol
"loadConst") returns a symbol whose print name is "loadConst", so they
are clearly distinguishable.
In other words, there is no way to type the symbol whose print name
is "loadConst", since READ canonicalizes 'loadConst to 'loadconst and
(eq? 'loadConst 'loadconst) -> #t
It would be nice if the reports included a procedure called INTERN (or
something like that) which when given a string, would canonicalize it
(transform it to the standard case) and then use string->symbol on it.
The report does not have such functionality, although it can be
defined portably (using some inessential procedures), albeit somewhat
awkwardly:
(define intern
(let ((standard-is-lower?
(string=? "a" (symbol->string 'A))))
(lambda (string)
(string->symbol
(list->string
(map (if standard-is-lower?
char-downcase
char-upcase)
(string->list string)))))))
MIT Scheme (>= 7.0) has INTERN pre-defined.
------------------------------
Message-ID: <1728@geocub.greco-prog.fr>
Date: 16 Mar 90 07:22:58 GMT
From: Pierre Casteran <mcsun!inria!litp!geocub!casteran@uunet.uu.net>
To: scheme@mc.lcs.mit.edu
Subject: Scheme for Amiga
I am looking for a Public Domain Scheme for Amiga; can somebody tell me how
to get it ?
Thanks in advance.
Pierre Casteran
------------------------------
Message-ID: <16824@well.sf.ca.us>
Date: 23 Mar 90 03:55:50 GMT
From: Jordan Bortz <snorkelwacker!apple!well!frobozz@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Getting scheme-7.0
Can someone give me the complete instructions for FTPing
c-scheme, including: host, filename, and directory?
I'm trying to use PUCC to bounce it thru usenet; PUCC
won't tell me the names of files in directories, I
don't think....
Jordan
--
***********************************************************************
* Jordan A. Bortz, Tigre Development Corp, Santa Cruz, CA
* well!frobozz frobozz@well.sf.ca.us
***********************************************************************
------------------------------
End of Scheme Digest
********************
∂23-Mar-90 0618 jinx@zurich.ai.mit.edu [oz@nexus.yorku.ca: ports...]
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Mar 90 06:18:29 PST
Received: from zurich.ai.mit.edu ([18.43.0.171]) by life.ai.mit.edu (4.0/AI-4.10) id AA04500; Fri, 23 Mar 90 09:15:49 EST
Received: from localhost by zurich.ai.mit.edu; Fri, 23 Mar 90 09:14:55 est
Date: Fri, 23 Mar 90 09:14:55 est
From: jinx@zurich.ai.mit.edu (Guillermo J. Rozas)
Message-Id: <9003231414.AA28565@zurich.ai.mit.edu>
To: rrrs-authors@zurich.ai.mit.edu
Subject: [oz@nexus.yorku.ca: ports...]
In-Reply-To: "Pavel_Curtis.PARC"@Xerox.COM's message of 22 Mar 90 11:47:31 PST (Thursday) <900322-121348-1029@Xerox>
Reply-To: jinx@zurich.ai.mit.edu
Actually, it seems like it's even more important to specify that
eof-object? is not true of anything that could be the result of a READ,
which includes everything on the list of disjoint types except
procedures.
Clearly EOF-OBJECTs are the result of READ when READ is invoked on an
file port at the "end of file", so we can't require EOF-OBJECTs not
to be returned by READ. Furthermore, I'm not sure that it is a good
idea to require that READ only return EOF-OBJECTs at the "end of
file". The rationale is as follows:
- Some systems may want to have the equivalent of #. (ugh!). We would
be requiring such systems to have a different reader, or to restrict
EVAL so that it could not return EOF-OBJECTs.
- Some systems may associate with each printed object some tag (a hash
number, interaction number, etc.) which may be used to specify at
read-time the object (so that printed procedures, for example, may be
referred to). Such systems would then have to special case
EOF-OBJECTs potentially printed by WRITE, for otherwise the user could
specify them via the tag.
Admittedly, in either case, the user might be in trouble since her/his
interaction stream might be closed behind them, but that is her/his
problem for trying to read an EOF-OBJECT, although that may have been
the intent (akin to typing ↑D in Unix).
I would not object to making EOF-OBJECTs distinct from any CHARACTER?,
although it's not clear to me that it is necessary or desirable, since
after all, it would only be natural for someone to implement
EOF-OBJECT? as a test for ASCII end-of-text.
At the meta level, I'm very worried about this frenzy to make
everything distinct from everything else. You are committing
implementations to either have more primitive types, or more expensive
type tests. In particular, I don't see how all this generalizes if we
ever attempt to integrate something like JAR's record package. At
that point we will have a RECORD? predicate, and to be perfectly
consistent, RECORDs should be disjoint from all other types, but that
would prevent me from representing ports (and perhaps even lists) as
records, which I don't think anyone desires.
I think we are gradually overspecifying this language, and we may
easily get ourselves into a hole.
∂24-Mar-90 0044 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #336
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 24 Mar 90 00:44:39 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA14966; Sat, 24 Mar 90 03:44:07 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Sat, 24 Mar 90 03:43:20 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa07118;
24 Mar 90 3:23 EST
Message-Id: <DIGEST.184.900324.024048.42@MC.LCS.MIT.EDU>
Date: 24 Mar 90 02:40:48 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #336
Scheme Digest #336 24 Mar 90 02:40:48 EST
Today's Topics:
Request for P.D. Lisp for the Cray
Bug in MIT-Scheme
----------------------------------------------------------------------
Message-ID: <416@forsight.Jpl.Nasa.Gov>
Date: 23 Mar 90 16:42:56 GMT
From: Erann Gat <elroy.jpl.nasa.gov!forsight!gat@locus.ucla.edu>
To: scheme@mc.lcs.mit.edu
Subject: Request for P.D. Lisp for the Cray
Does anyone know of a public domain (or relatively cheap, i.e. <$1000)
Lisp compiler which can produce code for a Cray Y/MP? A Lisp-->C translator
might work, but it would have to do a pretty good job of producing
efficient code in order to not defeat the purpose.
Please reply by E-mail: gat@ai.jpl.nasa.gov or gat@robotics.jpl.nasa.gov
Thanks in advance,
Erann Gat
Robotic Intelligence Group
Jet Propulsion Laboratory
------------------------------
Message-ID: <9003231556.aa09018@mintaka.lcs.mit.edu>
Date: Fri, 23 Mar 90 15:54:56 EST
From: Christopher Maeda <cmaeda@a.gp.cs.cmu.edu>
Reply-To: cmaeda@cs.cmu.edu
To: jinx@zurich.ai.mit.edu
CC: scheme@mc.lcs.mit.edu
Subject: Bug in MIT-Scheme
Date: Thu, 22 Mar 90 07:01:42 est
From: "Guillermo J. Rozas" <jinx@zurich.ai.mit.edu>
Reply-To: jinx@zurich.ai.mit.edu
It would be nice if the reports included a procedure called INTERN (or
something like that) which when given a string, would canonicalize it
(transform it to the standard case) and then use string->symbol on it.
The report does not have such functionality, although it can be
defined portably (using some inessential procedures), albeit somewhat
awkwardly:
It should be mentioned that Common Lisp doesn't do this either.
Calls to intern (in Common Lisp) need to upcase the symbol names.
ie
(intern "ZiPpY") ==> |ZiPpY|
(intern (string-upcase "ZiPpY")) ==> ZIPPY ;; depends on print case variable
------------------------------
End of Scheme Digest
********************
∂25-Mar-90 0035 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #337
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 25 Mar 90 00:35:45 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA23903; Sun, 25 Mar 90 03:35:08 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Sun, 25 Mar 90 03:34:16 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa29416;
25 Mar 90 3:19 EST
Message-Id: <DIGEST.184.900325.022528.47@MC.LCS.MIT.EDU>
Date: 25 Mar 90 02:25:28 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #337
Scheme Digest #337 25 Mar 90 02:25:28 EST
Today's Topics:
Bogus bug in MIT-Scheme
scheme for the cray
----------------------------------------------------------------------
Message-ID: <5835@tekcrl.LABS.TEK.COM>
Date: 23 Mar 90 22:55:51 GMT
From: Ken Dickey <zephyr.ens.tek.com!tekcrl!tekchips!kend@uunet.uu.net>
To: scheme@mc.lcs.mit.edu
Subject: Re: Bogus bug in MIT-Scheme
Here are a couple of somewhat more efficient versions of a portable
string->cannonical-symbol. The only difference is the use of DO vs
named LET {some people particularly dislike one or the other}.
[Just for fun... or should we discuss style and esthetics for a few
weeks? 8↑]
-Ken Dickey
;;==================
(define STRING->CANNONICAL-SYMBOL
(let ( (case-squasher (if (eq? 'a (string->symbol "A"))
char-upcase
char-downcase))
)
(lambda ( <string> )
(let* ( (str-len (string-length <string>))
(decaseified-string (make-string str-len))
)
(let loop ( (index (- str-len 1) ) )
(string-set! decaseified-string
index
(case-squasher (string-ref <string> index)))
(if (> index 0)
(loop (- index 1))
(string->symbol decaseified-string))
) ) )
) )
;;==================
(define STRING->CANNONICAL-SYMBOL
(let ( (case-squasher (if (eq? 'a (string->symbol "A"))
char-upcase
char-downcase))
)
(lambda ( <string> )
(let* ( (str-len (string-length <string>))
(decaseified-string (make-string str-len))
)
(do ( (index (- str-len 1) (- index 1)) )
( (< index 0) (string->symbol decaseified-string) )
(string-set! decaseified-string
index
(case-squasher (string-ref <string> index)))
) ) )
) )
------------------------------
Message-ID: <9003242231.AA14024@schizo.samsung.com>
Date: Sat, 24 Mar 90 10:57:24 EDT
From: gjc@mitech.com
Reply-To: gjc@mitech.com
To: scheme@mc.lcs.mit.edu
Subject: scheme for the cray
It seems to me that since CRAY CPU time costs serious money,
and that if you are going to do some serious lisp work over any
length of time on it, then it would justify the cost of getting
the common-lisp implementation from CRAY.
That is the Allegro Common Lisp, which has done pretty well on Macsyma,
usually an acid-test for a lisp. (You know how things can break when
you throw large strangely-styled programs at them).
-gjc
I've heard of a KCL port to the CRAY. But again, you have to look
at the cost of cpu time and the difference in runtime efficiency for
the code you are going to run.
------------------------------
End of Scheme Digest
********************
∂26-Mar-90 0023 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #338
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 26 Mar 90 00:23:14 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA02586; Mon, 26 Mar 90 03:22:43 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Mon, 26 Mar 90 03:21:48 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa17035;
26 Mar 90 2:55 EST
Message-Id: <DIGEST.184.900326.021029.52@MC.LCS.MIT.EDU>
Date: 26 Mar 90 02:10:29 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #338
Scheme Digest #338 26 Mar 90 02:10:29 EST
Today's Topics:
Prototyped Object System for Scheme
Bug in MIT-Scheme
string->symbol ?!
----------------------------------------------------------------------
Message-ID: <Mar.25.15.57.39.1990.26301@topaz.rutgers.edu>
Date: 25 Mar 90 20:57:43 GMT
From: "Mark C. Carroll <mccarrol@topaz.rutgers.edu>" <mccarrol@topaz.rutgers.edu>
To: scheme@mc.lcs.mit.edu
Subject: Prototyped Object System for Scheme
Hello all!
I'm a CS undergrad senior, working on an independant research project
in Object-oriented programming systems. As a part of this study, I've
written a Prototyped object-oriented package for the Fools Lisp
variant of Scheme. It's very nearly complete, and I'd like to find a
couple of people to play with it, and see if they can find bugs, or
make suggestions on it. Once it's passed through this group, I'll
be willing to give it away to anyone who wants it.
Anyway, I'm looking for people who'll be willing to test it for me.
The requirements are: a reliable mail path to/from Rutgers, a working
copy of Fools Lisp, and a willingness to play around with a minimally
documented prototype system.
I'm posting this at 3pm on Sunday, March 25. If you receive this
before Wednesday the 27th, and you're interested, please send me
email. If you recieve it at any time beyond midnight tuesday, please
don't reply yet. (Yes, it's a gimmick to keep me from getting 700
people wanting copies. I will be glad to eventually send it to
everyone who wants it, but for now, I want to keep the volume down!)
The address to reply to is:
mccarrol@topaz.rutgers.edu
In your reply, just tell me your name, and whether your a student or a
professional, etc. (just to satisfy my curiousity. It doesn't really
matter.)
Thanks!
<MC>
--
\ Mark Craig Carroll: <MC> |"Don't believe what your eyes are telling you. /
/ Student SysProg - LCSR | All they show is limitation. Look with your \
\ Rutgers University | understanding, find out what you already know,/
/ mccarrol@topaz.rutgers.edu| and you'll see the way to fly." -Richard Bach \
------------------------------
Message-ID: <1254@tub.UUCP>
Date: 22 Mar 90 09:50:24 GMT
From: Oliver Laumann <mcsun!unido!tub!net@uunet.uu.net>
To: scheme@mc.lcs.mit.edu
Subject: Re: Bug in MIT-Scheme
In article <2063@laura.UUCP> muenx@heike.informatik.uni-dortmund.de (Holger Muenx) writes:
> I think I found a small bug in MIT-Scheme V7.0. Look at the following
> transcript:
>
> 1 ]=> (eq? (string->symbol "loadConst") 'loadConst)
>
> ;Value: ()
It ain't no bug. The standard says (in the section explaining
symbol->string):
"If the symbol was part of an object returned as the value of a literal
expression [..] then the string returned will contain characters
in the implementations preferred standard case [..].
If the symbol was returned by string->symbol, the case of the
characters in the string returned will be the same as the case in
the string that was passed to string->symbol."
Thus, since 'loadConst is a literal, the characters are transformed into
the "preferred case" by the reader, which I think is upcase in C-Scheme,
i.e. the name of the symbol actually is LOADCONST.
On the other hand, the case of the characters in the name of the symbol
created by the above call to string->symbol is preserved, which is the
reason why eq? returns () (well, I wish it would return #f, but that's
another story...).
Now let me turn your attention to a real bug in C-Scheme:
The C-Scheme reader refuses to parse numeric constants like #o-10
(i.e. a radix followed by a sign followed by digits). On the other
hand, it happily accepts something like -#o10. This must be a bug,
since the standard clearly says that the radix, like the exactness
specification, is a prefix (see page 37 of the P1178/D3 or page 32
of the R↑3.99RS), so #o-10 is the correct form, while -#o10 should
be parsed into two objects, the symbol "-" followed by #o10.
Regards,
--
Oliver Laumann, Technical University of Berlin, Germany.
pyramid!tub!net net@TUB.BITNET net@tub.cs.tu-berlin.de
------------------------------
Message-ID: <2066@laura.UUCP>
Date: 23 Mar 90 15:46:55 GMT
From: Holger Muenx <mcsun!unido!laura!heike.informatik.uni-dortmund.de!muenx@uunet.uu.net>
To: scheme@mc.lcs.mit.edu
Subject: string->symbol ?!
Hi!
Thanks to all who answered to my posting according to a minor problem with
string->symbol when using upper/lower case letters in MIT-Scheme.
Ok, most of them said it's in the R3RS so this behaviour is correct. It's
really in R3RS -- I read it.
Here is my (naive) opinion to this point. May it be written in R3RS or not
-- I think it's disturbing. When do you want to have symbols which cannot
be typed from keyboard? Isn't it enough to use strings in these cases?
Someone said it's a relict from old Lisp times. There existed no strings so
they needed symbols which can consist of non-typable chars.
-Holger
=============================================================================
Holger Muenx muenx@heike.informatik.uni-dortmund.de
IRB, UniDo
4600 Dortmund "My opinions are shareware. Send $10
West-Germany if you like them."
------------------------------
End of Scheme Digest
********************
∂27-Mar-90 0117 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #339
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 27 Mar 90 01:16:59 PST
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.0/AI-4.10) id AA20088; Tue, 27 Mar 90 04:15:46 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Tue, 27 Mar 90 04:14:31 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa23068;
27 Mar 90 4:00 EST
Message-Id: <DIGEST.184.900327.031035.57@MC.LCS.MIT.EDU>
Date: 27 Mar 90 03:10:35 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #339
Scheme Digest #339 27 Mar 90 03:10:35 EST
Today's Topics:
Bug in MIT-Scheme (2 messages)
string->symbol ?!
Errata for article in _Lisp & Symbolic Computation_
Need more info on compiling scheme
----------------------------------------------------------------------
Message-ID: <9003261527.AA27414@zurich.ai.mit.edu>
Date: Mon, 26 Mar 90 10:27:15 est
From: "Guillermo J. Rozas" <jinx@zurich.ai.mit.edu>
Reply-To: jinx@zurich.ai.mit.edu
To: mcsun!unido!tub!net@uunet.uu.net
CC: scheme@MC.LCS.MIT.EDU
Subject: Bug in MIT-Scheme
Now let me turn your attention to a real bug in C-Scheme:
The C-Scheme reader refuses to parse numeric constants like #o-10
(i.e. a radix followed by a sign followed by digits). On the other
hand, it happily accepts something like -#o10. This must be a bug,
since the standard clearly says that the radix, like the exactness
specification, is a prefix (see page 37 of the P1178/D3 or page 32
of the R↑3.99RS), so #o-10 is the correct form, while -#o10 should
be parsed into two objects, the symbol "-" followed by #o10.
This is not a bug. The syntax of numbers has changed between R↑3RS
and R↑3.99RS. In R↑3RS, the sign preceded the radix specifier. Look
at the production for <number> on page 30. In R↑3.99RS (and
pressumably in the final version, R↑4RS), the radix specifier precedes
the sign. Since R↑4RS hasn't been released, nor has the IEEE standard
been approved, you can hardly expect a 1-year-old release of MIT
Scheme to match them.
C-Scheme beta release 7.1 (to be released sometime in the not-too-far
future) matches R↑3.99RS in the syntax and semantics of numbers.
------------------------------
Message-ID: <9003261530.AA27439@zurich.ai.mit.edu>
Date: Mon, 26 Mar 90 10:30:41 est
From: "Guillermo J. Rozas" <jinx@zurich.ai.mit.edu>
Reply-To: jinx@zurich.ai.mit.edu
To: mcsun!unido!laura!heike.informatik.uni-dortmund.de!muenx@uunet.uu.net
CC: scheme@MC.LCS.MIT.EDU
Subject: string->symbol ?!
Date: 23 Mar 90 15:46:55 GMT
From: Holger Muenx <mcsun!unido!laura!heike.informatik.uni-dortmund.de!muenx@uunet.uu.net>
Hi!
Thanks to all who answered to my posting according to a minor problem with
string->symbol when using upper/lower case letters in MIT-Scheme.
Ok, most of them said it's in the R3RS so this behaviour is correct. It's
really in R3RS -- I read it.
Here is my (naive) opinion to this point. May it be written in R3RS or not
-- I think it's disturbing. When do you want to have symbols which cannot
be typed from keyboard? Isn't it enough to use strings in these cases?
Someone said it's a relict from old Lisp times. There existed no strings so
they needed symbols which can consist of non-typable chars.
Consider building a parser in Scheme for a new dialect of Lisp. You
may want to share the "symbol table", since that may give you
convenient access to the primitives, yet you may want your new dialect
to be case-sensitive. Your parser could then use STRING->SYMBOL to
intern symbols, yet allow symbols in the "wrong" case, or mixed case.
Most programs will not exercise this capability, which is why I would
like to see a standard case-canonicalizing version of STRING->SYMBOL,
yet some programs may want it.
------------------------------
Message-ID: <6079@brazos.Rice.edu>
Date: 26 Mar 90 18:29:08 GMT
From: Dorai Sitaram <datura!dorai@rice.edu>
To: scheme@mc.lcs.mit.edu
Subject: Errata for article in _Lisp & Symbolic Computation_
The following is a list of errors in our article ``Control Delimiters
and their Hierarchies'' in _Lisp and Symbolic Computation_, Volume 3,
Number 1, pages 67--99.
1. The title page (p.67) gives my email address as ``dori@rice.edu''.
That should read ``dorai@rice.edu''. [BTW, the email addresses were
inserted by the editor after being left out intentionally by the
authors.]
2. The Scheme sub-expression starting on line 12 of Figure 3 (p.80)
reading:
(let ([invoke-sub-stack (cdr (car run-stack))])
(set-cdr! invoke-frame
(append ...)))
should read (as shown in the in-text code on p.81):
(let ([invoke-top-frame (car run-stack)])
(let ([invoke-sub-stack (cdr invoke-top-frame)])
(set-cdr! invoke-top-frame
(append ...))))
[This error was brought to our notice by a message from Pete Harlan,
Indiana University.]
3. The third reference on p.98 reading:
M. Felleisen. A calculus for assignments ...
should include another author and read:
M. Felleisen and D.P. Friedman. A calculus for assignments ...
4. The sixth reference on p.98 reading:
C.T. Haynes and D.P. Friedman. Abstracting timed preemption
with engines. Journal of Computer Languages (Pergamon Press),
12(2):109--121, 1987.
should have an _additional_ note reading:
Preliminary version: Engines build Process Abstractions. In
Proc. Conference on Lisp and Functional Programming, 1985,
18--24.
5. The 18th (and last) reference on p.99 reading:
G.J. Sussman and G.L. Steele Jr. Scheme: An interpreter for
the extended lambda calculus ...
should read:
G.J. Sussman and G.L. Steele Jr. Scheme: An interpreter for
extended lambda calculus ...
(i.e., no ``the''.)
--dorai
[Dorai Sitaram, dorai@rice.edu, Rice University, Houston TX]
------------------------------
Message-ID: <16879@well.sf.ca.us>
Date: 26 Mar 90 18:44:05 GMT
From: Jordan Bortz <snorkelwacker!apple!well!frobozz@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Need more info on compiling scheme
What files do I need from the SCHEME-7.0 distribution
to build a scheme for a Mac II? What changes to the files do I need
to make? Thanks for the info,
Jordan
--
***********************************************************************
* Jordan A. Bortz, Tigre Development Corp, Santa Cruz, CA
* well!frobozz frobozz@well.sf.ca.us
***********************************************************************
------------------------------
Message-ID: <9003262207.AA11761@life.ai.mit.edu>
Date: Mon, 26 Mar 90 17:07:17 est
From: Chris Hanson <cph@zurich.ai.mit.edu>
To: mcsun!unido!tub!net@uunet.uu.net
CC: scheme@mc.lcs.mit.edu
Subject: Bug in MIT-Scheme
Date: 22 Mar 90 09:50:24 GMT
From: Oliver Laumann <mcsun!unido!tub!net@uunet.uu.net>
Now let me turn your attention to a real bug in C-Scheme:
The C-Scheme reader refuses to parse numeric constants like #o-10
(i.e. a radix followed by a sign followed by digits). On the other
hand, it happily accepts something like -#o10. This must be a bug,
since the standard clearly says that the radix, like the exactness
specification, is a prefix (see page 37 of the P1178/D3 or page 32
of the R↑3.99RS), so #o-10 is the correct form, while -#o10 should
be parsed into two objects, the symbol "-" followed by #o10.
If you had read a little more carefully you would have found that the
syntax changed between R3RS and R3.99RS. MIT Scheme 6.1.2 and 7.0
conform to R3RS, accepting `-#o10' and refusing `#o-10'. The current
version of MIT Scheme, sometime to be released as version 7.1,
conforms to R3.99RS and the standard.
Given that neither the standard nor R4RS is yet finished, I think it's
fair to say that the current MIT Scheme conforms to current standards.
------------------------------
End of Scheme Digest
********************
∂29-Mar-90 0141 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #340
Received: from life (life.ai.mit.edu) by SAIL.Stanford.EDU with TCP; 29 Mar 90 01:41:21 PST
Received: from zurich.ai.mit.edu by life (4.1/AI-4.10) id AA16857; Thu, 29 Mar 90 04:40:35 EST
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Thu, 29 Mar 90 03:35:15 est
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa20846;
29 Mar 90 3:18 EST
Message-Id: <DIGEST.184.900329.024038.66@MC.LCS.MIT.EDU>
Date: 29 Mar 90 02:40:37 EST
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #340
Scheme Digest #340 29 Mar 90 02:40:37 EST
Today's Topics:
hygienic macro expansion
Scheme and Databases
----------------------------------------------------------------------
Message-ID: <6132@brazos.Rice.edu>
Date: 28 Mar 90 18:08:28 GMT
From: Matthias Felleisen <leto!matthias@rice.edu>
To: scheme@MC.lcs.mit.edu
Subject: hygienic macro expansion
Recent references to "hygienic macro expansion" [1] on this mailing
list, in technical reports, and in publications indicate that there is
a prevailing misunderstanding about the term. Our original paper
proved a simple idea: there are macro expansion ALGORITHM(s) that
prevent the accidental capture of free variables by macro-introduced
bindings, and it is therefore unnecessary [indeed we argued that it
was dangerous] to rely on the MACRO PROGRAMMER (macrologist) to do so.
We showed that this is possible by using the simple, existing macro
tools of Lisp as a "target" macro system. This may also be possible
with other target systems such as syntactic closures [2] or other
macro tools, but this is besides the point. Macrologists can program
safely in all systems but the point of hygienic expansion is that a
system builder can ENFORCE such a discipline with an appropriate macro
expander.
-- Bruce Duba and Matthias Felleisen, Rice University
[1] {Kohlbecker E., D.P. Friedman, M. Felleisen, and B.F. Duba}.
Hygienic macro expansion. In {\it Proc. 1986 ACM Conference on Lisp
and Functional Programming}, 1986, 151--161.
[2] {Bawden, A. and J. Rees}. Syntactic closures. In {\it Proc. 1988
ACM Conference on Lisp and Functional Programming}, 1988, 86--95.
------------------------------
Message-ID: <9003282322.AA26183@tekadg.adg.tek.com>
Date: 28 Mar 90 15:22:47 PST (Wed)
From: tims@tekadg.adg.tek.com
To: scheme@mc.lcs.mit.edu
Subject: Scheme and Databases
I would appreciate pointers to database work that uses Scheme,
particularly object-oriented databases.
Thanks, Tim Sauerwein, Tektronix, Inc. tims@tekadg.adg.tek.com
------------------------------
End of Scheme Digest
********************
∂01-Apr-90 1454 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #341
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Apr 90 14:54:46 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA11229; Sun, 1 Apr 90 17:52:02 EDT
Received: from life.ai.mit.edu (life.ai.mit.edu) by zurich.ai.mit.edu; Sun, 1 Apr 90 17:50:21 edt
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA11228; Sun, 1 Apr 90 17:51:37 EDT
Received: by mintaka.lcs.mit.edu id ar01212; 1 Apr 90 17:31 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa14606;
1 Apr 90 4:10 EDT
Message-Id: <DIGEST.184.900401.034837.4@MC.LCS.MIT.EDU>
Date: 1 Apr 90 03:48:37 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #341
Scheme Digest #341 1 Apr 90 03:48:37 EDT
Today's Topics:
Elk?
----------------------------------------------------------------------
Message-ID: <1990Mar30.205552.11992@eplrx7.uucp>
Date: 30 Mar 90 20:55:52 GMT
From: Walt Leipold <eplrx7!leipold@louie.udel.edu>
To: scheme@mc.lcs.mit.edu
Subject: Elk?
From what site can I ftp the latest version of ELK?
Thanks...
--
"As long as you've lit one candle, Walt Leipold
you're allowed to curse the darkness." (leipolw%esvax@dupont.com)
--
--
The UUCP Mailer
------------------------------
End of Scheme Digest
********************
∂01-Apr-90 2356 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #342
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Apr 90 23:55:57 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA16270; Mon, 2 Apr 90 02:54:43 EDT
Received: from life.ai.mit.edu (life.ai.mit.edu) by zurich.ai.mit.edu; Mon, 2 Apr 90 02:53:10 edt
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA16264; Mon, 2 Apr 90 02:54:26 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa21047;
2 Apr 90 2:43 EDT
Message-Id: <DIGEST.184.900402.021838.8@MC.LCS.MIT.EDU>
Date: 2 Apr 90 02:18:38 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #342
Scheme Digest #342 2 Apr 90 02:18:38 EDT
Today's Topics:
Bug in MIT-Scheme
Elk?
----------------------------------------------------------------------
Message-ID: <9004011103.AA12280@tub.UUCP>
Date: Sun, 1 Apr 90 12:03:15 +0100
From: Oliver Laumann <net%TUB.BITNET@mitvma.mit.edu>
To: Scheme@lcs.mit.edu, jinx@zurich.ai.mit.edu
Subject: Re: Bug in MIT-Scheme
> The C-Scheme reader refuses to parse numeric constants like #o-10
> [...]
>
> This is not a bug. The syntax of numbers has changed between R↑3RS
> and R↑3.99RS. [...]
I'm sorry. I made the mistake to throw away my copy of the R↑3RS when
I obtained a copy of the R↑3.99RS. Anyway, when the number syntax has
changed between R↑3RS and R↑3.99RS, shouldn't this fact be listed in
the ``Language Changes'' appendix of the report?
--
Oliver Laumann net@TUB.BITNET net@tub.cs.tu-berlin.de net@tub.UUCP
------------------------------
Message-ID: <1262@tub.UUCP>
Date: 1 Apr 90 12:45:00 GMT
From: Oliver Laumann <eru!luth!sunic!mcsun!unido!tub!net@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: Elk?
In article <1990Mar30.205552.11992@eplrx7.uucp> leipold@eplrx7.UUCP (Walt Leipold) writes:
> From what site can I ftp the latest version of ELK?
Since the latest version of Elk is the one on my site and since this site
does not (yet) have international FTP access, the answer is "You can't.".
However, I can send you a copy by e-mail. If you want this, drop me a
letter with your BITNET or Internet mail address.
--
Oliver Laumann net@TUB.BITNET net@tub.cs.tu-berlin.de net@tub.UUCP
------------------------------
End of Scheme Digest
********************
∂02-Apr-90 2334 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #343
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 2 Apr 90 23:34:11 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA22865; Tue, 3 Apr 90 02:31:28 EDT
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Tue, 3 Apr 90 02:29:41 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa19518;
3 Apr 90 2:20 EDT
Message-Id: <DIGEST.184.900403.020343.14@MC.LCS.MIT.EDU>
Date: 3 Apr 90 02:03:43 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #343
Scheme Digest #343 3 Apr 90 02:03:43 EDT
Today's Topics:
Futures in Scheme?
Elk?
The Haskell Report
Public Scheme for Atari ST
SPARC, Intel 386, and SUN3 ports of Scheme->C
----------------------------------------------------------------------
Message-ID: <246:lutzebaeck@fokus.berlin.gmd.dbp.de>
Date: 02 Apr 90 08:08 GMT+0200
From: Dirk Lutzebaeck <lutzebaeck@fokus.berlin.gmd.dbp.de>
To: scheme@mc.lcs.mit.edu
Subject: Futures in Scheme?
Hello schemers,
has anybody made some experiences in using the multiprocessing and/or
future extensions of MIT-CScheme (Version 6.1 or 7.0)?
I'm desparately looking for any documentation (or examples) besides
the source code (future.{c,h}, intercom.c) which is really hard to
read as a documentation. Unfortunately, the MIT CScheme-7.0 manual
leaves this topic (chapter 7.12) blank.
Does anybody know the exact parameterisation of the future- and
intercom-primitives?
Has anybody written an actor-language (something like "ACT 3") using
scheme (running on single-processor UNIX-Machines)?
Thanks for help,
--
Dirk Lutzebaeck | Voice: +49 30 25499-227
GMD-FOKUS | Email: lutzebaeck@fokus.berlin.gmd.dbp.de || dirk@tub.UUCP
Hardenbergplatz 2 | Bang: ...!pyramid!tub!dirk (from the US)
D-1000 Berlin 12 | or ...!mcvax!unido!tub!dirk (from Europe)
------------------------------
Message-ID: <1990Apr2.065227.19173@iam.unibe.ch>
Date: 2 Apr 90 06:52:27 GMT
From: Igor Metz <eru!luth!sunic!mcsun!cernvax!chx400!iam!metz@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: Elk?
In article <1262@tub.UUCP> net@tub.UUCP (Oliver Laumann) writes:
>In article <1990Mar30.205552.11992@eplrx7.uucp> leipold@eplrx7.UUCP (Walt Leipold) writes:
>> From what site can I ftp the latest version of ELK?
>
>Since the latest version of Elk is the one on my site and since this site
>does not (yet) have international FTP access, the answer is "You can't.".
>However, I can send you a copy by e-mail. If you want this, drop me a
>letter with your BITNET or Internet mail address.
You can ftp the version which I got from Oliver Laumann from iamsun.unibe.ch
[130.92.64.10]. You'll find it in ~ftp/Languages/ELK.tar.Z (333655 Bytes).
--
Igor Metz X400: metz@iamsm.iam.unibe.ch
Institut fuer Informatik ARPA: metz%iamsm.iam.unibe.ch@relay.cs.net
und angewandte Mathematik UUCP: ..!uunet!mcsun!iamsm.iam.unibe.ch!metz
Universitaet Bern Phone: (0041) 31 65 49 90
------------------------------
Message-ID: <21057@cs.yale.edu>
Date: 2 Apr 90 15:11:41 GMT
From: maria guzman <cs.yale.edu!guzman-maria@yale-zoo.arpa>
To: scheme@mc.lcs.mit.edu
Subject: The Haskell Report
Announcing
The Haskell Report
Version 1.0
1 April 1990
The Haskell Committee, formed in September 1987 to design a "common"
non-strict purely functional language, has (finally) completed its work
and wishes to announce a Report about the language. Several preliminary
versions of the Report were released to get feedback, and many changes
have been incorporated since the first release in December '88. The
current release will remain STABLE for at least one year.
You may get the report via anonymous FTP:
from Yale: from Glasgow:
ftp nebula.cs.yale.edu ftp cs.glasgow.ac.uk
(or ftp 128.36.13.1)
login: anonymous login: guest
password: anonymous password: <your username>
type binary type binary
cd pub/haskell-report cd <FP>haskell-report
get report-1.0.tar.Z get report-1.0.tar.Z
get report-1.0.dvi.Z get report-1.0.dvi.Z
get report-1.0.ps.Z get report-1.0.ps.Z
quit quit
The .tar file contains the source document in Unix tape archive
format; alternatively the .dvi or .ps files may be used for printing
only. All of the files are in compress format; to uncompress them
type "uncompress <filename>" at the Unix shell. The report is over
100 pages long and has been formatted for double-sided copying.
Alternatively, you may get a hard copy by:
Sending $10 to: Sending 5 pounds to:
The Haskell Project The Haskell Project
Department of Computer Science Department of Computing Science
Yale University University of Glasgow
Box 2158 Yale Station Glasgow G12 8QQ
New Haven, CT 06520 USA SCOTLAND
Two implementations of Haskell will soon be available, one built at the
University of Glasgow, the other at Yale University. Watch this space
for announcements.
Finally, we hope to fix, improve and clarify the current Haskell design
through graceful evolution and with your help. To this end, several
mailing lists have been set up:
1) A common mailing list for general discussions about Haskell.
This list is reachable in one of two ways:
haskell@cs.yale.edu or haskell@cs.glasgow.ac.uk
2) To be added to the above mailing list, or to inquire about
the implementation status of Haskell, send mail to either:
haskell-request@cs.yale.edu or haskell-request@cs.glasgow.ac.uk
(whichever is the nearer site to you).
3) The implementation efforts at Glasgow and Yale will have their own
mailing lists for users of the respective systems. These will be
announced at the time the implementations are released.
------------------------------
Message-ID: <1795@geocub.greco-prog.fr>
Date: 2 Apr 90 10:21:53 GMT
From: Pierre Casteran <eru!luth!sunic!mcsun!inria!geocub!casteran@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Public Scheme for Atari ST
Can somebody give me some pointer to a public domain Scheme for Atari ST (520 Ko) ?
thanks in advance
P. Casteran
------------------------------
Message-ID: <9004022332.AA09556@jove.pa.dec.com>
Date: Mon, 02 Apr 90 16:32:51 PDT
From: bartlett@wrl.dec.com
To: Scheme@lcs.mit.edu
CC: bartlett@wrl.dec.com
Subject: SPARC, Intel 386, and SUN3 ports of Scheme->C
Roger Critchlow <rec@arris.com> and Mikael Pettersson <mpe@IDA.LiU.SE> have
completed ports of Scheme->C to SPARC, Intel 386, and SUN3 and have
mailed me the patches.
They are available for anonymous ftp from 'gatekeeper.dec.com'
[16.1.0.2]. The Scheme->C files and patches are in
'/pub/DEC/Scheme-to-C'. The files include:
README - overview and copyright notice.
23feb90.tar.Z - compressed tar file containing all source
and documentation.
SPARC-386.patches - patches for SPARC and Intel 386.
SUN3.patches - patches for SUN3.
I congratulate them for their efforts and their comments on how to make
Scheme->C more portable.
jfb
------------------------------
End of Scheme Digest
********************
∂04-Apr-90 1222 @zurich.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu ports (really disjointness of types)
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 4 Apr 90 12:22:33 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA21235; Wed, 4 Apr 90 15:16:52 EDT
Received: from skinner.cs.uoregon.edu (skinner.cs.uoregon.edu) by zurich.ai.mit.edu; Wed, 4 Apr 90 15:14:34 edt
Received: from spencer.cs.uoregon.edu by skinner.cs.uoregon.edu with SMTP
(5.61.14/IDA-1.2.8) id AA23106; Wed, 4 Apr 90 12:14:48 -0700
Received: by spencer.cs.uoregon.edu; Wed, 4 Apr 90 12:14:40 PDT
Date: Wed, 4 Apr 90 12:14:40 PDT
From: will@cs.uoregon.edu
Message-Id: <9004041914.AA10982@spencer.cs.uoregon.edu>
To: rrrs-authors@zurich.ai.mit.edu
Subject: ports (really disjointness of types)
[I attempted to send this message two weeks ago, but it apparently
failed to get out of Oregon. (We've had software problems since
one of our disk drives died.) In answer to oz's question to
scheme-standard, I favor a type hierarchy (though not the one oz
suggests). That is, I don't see the point of trying to split the
entire space of objects into a canonical set of pigeonholes, but
I do see that requiring certain common types to be disjoint makes
it easier to write portable code. Furthermore it is essential to
my understanding of Scheme that certain types overlap; see examples
below.]
why...are [ports] somehow kept out of the "disjointness of types" ??
Without answering this question, does anyone know whether there
might be any significant benefit to allowing the set of input ports
to overlap with the set of output ports? I am aware of claims that
this is useful, but I'd like to understand why. (I am not impressed
by the convenience of packaging two ports within a single object,
which is the only explanation I have heard.)
Actually, it seems like it's even more important to specify that
eof-object? is not true of anything that could be the result of a READ,
which includes everything on the list of disjoint types except
procedures.
This is specified already as part of the description of EOF-OBJECT?.
Clearly EOF-OBJECTs are the result of READ when READ is invoked on an
file port at the "end of file", so we can't require EOF-OBJECTs not
to be returned by READ....
That's why the description of EOF-OBJECT? does not say that end
of file objects cannot be returned by READ, but says instead that
"no end of file object will ever be an object that can be read
in using READ".
In particular, I don't see how all this generalizes if we
ever attempt to integrate something like JAR's record package. At
that point we will have a RECORD? predicate, and to be perfectly
consistent, RECORDs should be disjoint from all other types, but that
would prevent me from representing ports (and perhaps even lists) as
records, which I don't think anyone desires.
To be perfectly consistent we will have to decide, or fail to
decide, how we want records to fit into the subtype structure
we've been constructing for Scheme. We already have types that
overlap: the type of LIST overlaps with the types of PAIR and the
type NULL, but the most impressive example is the type structure
of numbers:
NUMBER
/ | \
/ | \
EXACT | INEXACT
| | |
| COMPLEX |
| / | \ |
| / | \ |
EXACT COMPLEX | INEXACT COMPLEX
| | |
| REAL |
| / | \ |
| / | \ |
EXACT REAL | INEXACT REAL
| | |
| RATIONAL |
| / | \ |
| / | \ |
EXACT RATIONAL | INEXACT RATIONAL
| | |
| INTEGER |
| / | \ |
| / | \ |
EXACT INTEGER INEXACT INTEGER
There's no official type structure for Scheme, of course, so
anyone can deny that any of these examples are really types.
On the other hand it's quite useful to regard them as types,
and so for expository purposes the R*RS speaks of them as
though they were (e.g. in sections 1.3.3 and 6.5 of R3.99RS).
My point is that it would be perfectly consistent to allow the
type RECORD to overlap with every type defined in the R*RS,
thereby allowing implementations in which all objects are
RECORDs. Furthermore I believe this would be desirable.
Peace, Will
∂05-Apr-90 2338 dyb@iuvax.cs.indiana.edu Re: ports (really disjointness of types)
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 5 Apr 90 23:38:39 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA17829; Thu, 5 Apr 90 22:08:13 EDT
Received: from iuvax.cs.indiana.edu (iuvax.cs.indiana.edu) by zurich.ai.mit.edu; Thu, 5 Apr 90 22:06:42 edt
Message-Id: <9004060206.AA00041@zurich.ai.mit.edu>
Received: by iuvax.cs.indiana.edu
Date: Thu, 5 Apr 90 21:06:54 -0500
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
To: rrrs-authors@zurich.ai.mit.edu
Subject: Re: ports (really disjointness of types)
> why...are [ports] somehow kept out of the "disjointness of types" ??
>
> Without answering this question, does anyone know whether there
> might be any significant benefit to allowing the set of input ports
> to overlap with the set of output ports? I am aware of claims that
> this is useful, but I'd like to understand why. (I am not impressed
> by the convenience of packaging two ports within a single object,
> which is the only explanation I have heard.)
This may be simply a question of convenience, but it would seem strange
to me that I would need two ports for one file that is open for both
reading and writing. Certainly it would seem strange as well as
inefficient to have to seek to a given record on both ports in order to
modify the record. And it may be difficult to totally separate the
input and output ports for a read/write file opened "exclusively", or
there may be an efficiency penalty for doing so.
I'll turn the question around. Does anyone know whether there might be
any significant benefit to not allowing the set of input ports to
overlap the set of output ports? I almost never use input-port? except
to check to see if I can read from a port before doing so, and I could
not care less if it were also valid to write to the port in that
context. If we're going to make a restriction that might possibly make
someone's fancy I/O interface clumsy or inefficient, we should have a
very good reason for doing so.
Kent
∂07-Apr-90 0026 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #344
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 7 Apr 90 00:26:21 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA09327; Sat, 7 Apr 90 03:19:06 EDT
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Sat, 7 Apr 90 03:17:24 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa09249;
7 Apr 90 3:08 EDT
Message-Id: <DIGEST.184.900407.024915.33@MC.LCS.MIT.EDU>
Date: 7 Apr 90 02:49:15 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #344
Scheme Digest #344 7 Apr 90 02:49:15 EDT
Today's Topics:
using a serial port in MacScheme
Anomalous behavior of fluid-let (ELK)
Chez Scheme (4 messages)
Is XScheme ftp-able ?
debugger for MacScheme
comp.lang.functional
Announcing SCIX version 0.96 availability.
Scheme debuggers
StratDes.scm <= here is it! (2 messages)
Scheme for 386
----------------------------------------------------------------------
Message-ID: <9004061557.AA26583@life.ai.mit.edu>
Date: Fri, 6 Apr 90 11:56:08 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: using a serial port in MacScheme
Date: Thu, 5 Apr 90 16:29 MET
From: "E HOENKAMP, TEL. 080-512605" <EDH%KUNRC1.URC.KUN.NL@cunyvm.cuny.edu>
Subject: using a serial port in MacScheme
To: scheme-request@mc.lcs.mit.edu
I would like to hook up a manipulator to my Mac and have it
take instructions from Scheme. So far I simulated the movements in
the graphics window, but it seems much more fun to let it happen in
the real world. Has anyone written code to do I/O via the serial
port? (Yes, I have consulted the toolsmith code that comes with
MacScheme).
Edward.
------------------------------
Message-ID: <1270@tub.UUCP>
Date: 4 Apr 90 10:53:41 GMT
From: Oliver Laumann <snorkelwacker!ira.uka.de!fauern!tub!net@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: Anomalous behavior of fluid-let (ELK)
In article <KENNY.90Mar28200242@jarrett.bert> kenny@jarrett.bert (Ken Wakita) writes:
>
> It seems that when the control returns back, instead of assigning
> n bound in fluid-let, ELK assigns the variable defined in the global
> environment to the old value which n bound in fluid-let was assigned
> at the invocation of test1 [...]
>
> I also found, that ELK does not handle mutually tail recursive
> function so well as MIT scheme.
You have just found two of the four known bugs (known to me, that is)
in Elk. fluid-let in Elk does not correctly preserve side-effects to
the variables in the binding list that occur inside or outside of the
fluid-let. Then again, fluid-let isn't part of the Scheme standard
anyway... :-)
Tail call optimization is only performed on directly recursive functions.
> By the way, I do not have the latest version of scheme report.
> Please let me know how I can ftp one.
You can FTP the reports from zurich.ai.mit.edu (pub/scheme-reports).
Regards,
--
Oliver Laumann net@TUB.BITNET net@tub.cs.tu-berlin.de net@tub.UUCP
------------------------------
Message-ID: <1803@geocub.greco-prog.fr>
Date: 4 Apr 90 13:54:00 GMT
From: Pierre Casteran <mcsun!inria!geocub!casteran@uunet.uu.net>
To: scheme@mc.lcs.mit.edu
Subject: Chez Scheme
I would appreciate some information about Chez Scheme:
Is it public domain? if not, how much it is ?
How can we get it ?
On what machines (Sun3 (?)) it runs ?
Thanks in advance
[Pierre Casteran]
------------------------------
Message-ID: <3279@jato.Jpl.Nasa.Gov>
Date: 4 Apr 90 18:43:18 GMT
From: Brian of ASTD-CP <snorkelwacker!usc!cs.utexas.edu!hp-sdd!elroy.jpl.nasa.gov!jato!granite!brian@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Is XScheme ftp-able ?
Sorry if the is the bazillion-th time this has been asked, but I'm
getting desperate. Is there an ftp site, an archive server, or
mechanism OTHER THAN the MIPS BBS (which I cannot get to) for
getting the XScheme 0.22, which I understand is the latest version ?
brian
------------------------------
Message-ID: <40731@iuvax.cs.indiana.edu>
Date: 5 Apr 90 00:59:32 GMT
From: Haydn Huntley <silver!huntley@iuvax.cs.indiana.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: Chez Scheme
In article <1803@geocub.greco-prog.fr> casteran@geocub.greco-prog.fr (Pierre Casteran) writes:
| I would appreciate some information about Chez Scheme:
|
| Is it public domain? if not, how much it is ?
| How can we get it ?
| On what machines (Sun3 (?)) it runs ?
Chez Scheme is an incredibly efficient, interactive Scheme compiler.
It is *NOT* public domain. I think it costs around $1000. It is available
from the author, R. Kent Dybvig, and his login is: dyb@iuvax.cs.indiana.edu
I use it several hours a day on a VAX, but it also runs on Sun3's and
SPARC Stations. There may also be other versions for NeXT and other machines.
--Haydn
------------------------------
Message-ID: <1990Apr2.211330.4693@mentor.com>
Date: 2 Apr 90 21:13:30 GMT
From: Chris Rosebrugh <tektronix!sequent!mntgfx!chrisr@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: debugger for MacScheme
Does anybody know of, or have, a debugger that i can use with MacScheme?
At this point, i'll try anything - even if it hasn't been proven to
work with MacScheme, but it'll be easiest if it's written in scheme.
Tracing and displaying just aren't cutting it anymore. i want to step!
Thanks for any leads.
--
Chris Rosebrugh | ...!{decwrl,sequent,tessi}!mntgfx!chrisr
Mentor Graphics Corporation | chrisr@pdx.MENTOR.COM
Beaverton, Oregon |
------------------------------
Message-ID: <CARLTON.90Apr5134904@husc9.harvard.edu>
Date: 5 Apr 90 17:49:04 GMT
From: david carlton <carlton@husc6.harvard.edu>
To: scheme@mc.lcs.mit.edu
Subject: comp.lang.functional
Comp.lang.functional passed, 305 to 7. Many thanks to those of you who voted.
It should appear in a week or so. I posted a list of votes received to
news.groups and news.announce.newgroups - if you're curious, look in one of
those groups.
Enjoy,
David Carlton
carlton@husc4.harvard.edu
------------------------------
Message-ID: <109@cadence.UUCP>
Date: 5 Apr 90 19:15:21 GMT
From: "R. Kent Dybvig" <cadence!dyb@iuvax.cs.indiana.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: Chez Scheme
> Is it public domain? if not, how much it is ?
> How can we get it ?
> On what machines (Sun3 (?)) it runs ?
Chez Scheme currently runs on 680x0-based Apollo, Sun-3, Sun-4, VAX
Ultrix, VAX VMS, and certain mc88000-based systems, and on a few other
(mostly 680x0-based) systems as well. Chez Scheme prices start at
$1000 for one personal workstation or $1500 for one multiuser machine
or server. Academic discounts (50%) and site licenses are available.
If you would like more information on Chez Scheme and how to order it,
send email to "dyb@cadence.bloomington.in.us" and I'll send you the
appropriate information. Please include your physical mail address in
your note.
Kent
R. Kent Dybvig | cadence!dyb@iuvax.cs.indiana.edu
Cadence Research Systems | or dyb@cadence.bloomington.in.us
620 Park Ridge Road | (also: dyb@iuvax.cs.indiana.edu)
Bloomington, IN 47408 | phone: 812/333-9269
------------------------------
Message-ID: <1990Apr4.132127.25405@nada.kth.se>
Date: 4 Apr 90 13:21:27 GMT
From: Johan Ihren <eru!luth!sunic!kth.se!draken!johani@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Announcing SCIX version 0.96 availability.
We are pleased to announce the public release of SCIX version 0.96.
It is available for anonymous FTP at ftp.kth.se in the directory
pub/Xcontrib/Toolkits/Scix and it will also be put on expo.lcs.mit.edu
in the contrib directory as soon as we can reach it. The files involved
are scix.README (short description of the system), scix-0.96.tar.Z
(the system) and scix-report.ps.Z (a technical report describing the system.)
The following is the scix.README file:
SCIX -- A Scheme Interface to the X Window System
The file scix-0.96.tar.Z contains the entire source for the SCIX system.
SCIX is a completely object-oriented interface between the X Window System
and the programming language Scheme. It is currently at version 0.96, i.e.,
it is a beta release.
It has been implemented with the Scheme->C system developed at Digital
Western Research Laboratory in Palo Alto by Joel Bartlett (Scheme->C is
available by anonymous ftp from gatekeeper.dec.com [16.1.0.2]). A
consequence of this is that SCIX is currently only working on architectures
that Scheme->C works on. Today this is primarily DECstations and VAXes.
Ports of Scheme->C to Sun3, Sun386 and Sparc were announced today
(3 April 90) and SCIX does build and run on at least the Sparc, but we
have not had the time to test them properly yet. Both SCIX and Scheme->C
should be rather easy to port. Most of the SCIX system is written in
standard Scheme (according to the R↑3.99RS). A few low-level routines
are written in C. No programming libraries (like Xlib or Xt) are used
to generate SCIX, but some include files from the X distribution are.
The added functionality is primarily described in our report, the PostScript
source of which is available in the file scix-report.ps.Z. A few sample
demonstrations are provided with the system.
To install, SCIX needs approximately 10 Mb of disk space. The built system
consists of a SCIX interpreter of 1.8 Mb (including demos), and two libraries
taking up less than 2 Mb. A minimal interpreter is just below 1 Mb in size.
The entire SCIX system was developed by us as the subject of our masters
thesis. The project was initiated, advised, and sponsored by Magnus Persson
at Digital Equipment AB, Sweden.
Hakan Huss and Johan Ihren
<huss@nada.kth.se> and <johani@nada.kth.se>
Department of Computing Science (NADA),
Royal Institute of Technology (KTH), Stockholm, Sweden
------------------------------
Message-ID: <7429@ubc-cs.UUCP>
Date: 5 Apr 90 15:42:41 GMT
From: Vincent Manis <ubc-cs!manis@beaver.cs.washington.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: Chez Scheme
I've been using Chez Scheme for the past year or so, in conjunction with
a prototype section of our new first year course. I have been incredibly
impressed with the performance and reliability of the product, and with
the fast response of Kent Dybvig's company, Cadence Research, to
problems. The system as delivered does not have an incredibly friendly
environment as far as naive users are concerned, but we got it running
as a GNU Emacs inferior process with almost no trouble, and this summer
plan to build a nice environment for introductory students with it.
It supports very easy linking to C foreign procedures, which enabled us
to build a simple graphics package very easily.
As a result of our experience with it this year, our RFP for a first
year UNIX laboratory specified support of Chez Scheme as a mandatory
requirement.
As far as a comparison with CScheme (also an excellent package): CScheme
is free, Chez Scheme costs US$1000/copy (with a 50% education discount,
and very generous site licencing). CScheme has a richer language dialect
than Chez Scheme. Neither is incredibly well documented. However,
performance, reliability, and (most especially important for us) support
and maintenance render Chez Scheme an outstanding product.
Standard disclaimer: I have no affiliation with Cadence Research, other
than being an extremely satisfied customer.
--
\ Vincent Manis <manis@cs.ubc.ca> "There is no law that vulgarity and
\ Department of Computer Science literary excellence cannot coexist."
/\ University of British Columbia -- A. Trevor Hodge
/ \ Vancouver, BC, Canada V6T 1W5 (604) 228-2394
------------------------------
Message-ID: <1990Apr5.213843.13690@mentor.com>
Date: 5 Apr 90 21:38:43 GMT
From: Chris Rosebrugh <tektronix!sequent!mntgfx!chrisr@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Scheme debuggers
Does anybody know of, or have, a debugger that i can use with MacScheme?
At this point, i'll try anything - even if it hasn't been proven to
work with MacScheme, but it'll be easiest if it's written in scheme.
Tracing and displaying just aren't cutting it anymore. i want to step!
Thanks for any leads.
--
Chris Rosebrugh | ...!{decwrl,sequent,tessi}!mntgfx!chrisr
Mentor Graphics Corporation | chrisr@pdx.MENTOR.COM
Beaverton, Oregon |
------------------------------
Message-ID: <2020002@hppad.HP.COM>
Date: 4 Apr 90 13:33:56 GMT
From: Carlos Bazzarella <hpfcso!hppad!bazza@hplabs.hp.com>
To: scheme@mc.lcs.mit.edu
Subject: Re: StratDes.scm <= here is it!
Ops, I meant to say : StratDes.scm <= where is it!
------------------------------
Message-ID: <2020001@hppad.HP.COM>
Date: 4 Apr 90 13:32:10 GMT
From: Carlos Bazzarella <hpfcso!hppad!bazza@hplabs.hp.com>
To: scheme@mc.lcs.mit.edu
Subject: StratDes.scm <= here is it!
Does anybody has the file STRATDES.SCM, which
contains the scheme source code of the article
"Lisp: A Language for Stratified Design" from
the february 1988/vol.13 no.2 Byte magazine.
I would also be interested in sources of
related articles from the same magazine,
It has "in depth" of lisp, specially scheme.
thanx in advance.
Carlos Bazzarella.
bazza@hppad
------------------------------
Message-ID: <1990Apr6.124034.2392@ibmpcug.co.uk>
Date: 6 Apr 90 12:40:34 GMT
From: Alan Hunter <mcsun!ukc!slxsys!ibmpcug!ahunter@uunet.uu.net>
To: scheme@mc.lcs.mit.edu
Subject: Scheme for 386
I have MIT Cscheme 6.1 running under Esix V.3.2 on a 386.
1. Are there significant changes in Cscheme v 7?
2. Do either Chez Scheme or T run on a 386 platform yet?
Thanks
Alan Hunter
--
Automatic Disclaimer:
The views expressed above are those of the author alone and may not
represent the views of the IBM PC User Group.
--
------------------------------
End of Scheme Digest
********************
∂11-Apr-90 0007 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #345
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 11 Apr 90 00:07:02 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA06359; Wed, 11 Apr 90 03:05:50 EDT
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Wed, 11 Apr 90 03:04:17 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa11406;
11 Apr 90 2:59 EDT
Message-Id: <DIGEST.184.900411.023505.48@MC.LCS.MIT.EDU>
Date: 11 Apr 90 02:35:05 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #345
Scheme Digest #345 11 Apr 90 02:35:05 EDT
Today's Topics:
Portable object oriented scheme systems
----------------------------------------------------------------------
Message-ID: <RAIBLE.90Apr10173310@ew09.nas.nasa.gov>
Date: 11 Apr 90 00:33:10 GMT
From: "Eric L. &" <amelia!raible@AMES.ARC.NASA.GOV>
To: scheme@mc.lcs.mit.edu
Subject: Portable object oriented scheme systems
I'm interested in any portable object oriented systems for scheme, or
a non-portable one based on xscheme.
In particular, I've heard that AMOS and SCOOPS are two good
candidates. I'd especially appreciate any information about them.
Feel free to post or mail, as you desire.
Thanks in advance,
Eric Raible (raible@nas.nasa.gov)
------------------------------
End of Scheme Digest
********************
∂14-Apr-90 0043 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #346
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 14 Apr 90 00:42:59 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA09805; Sat, 14 Apr 90 03:38:07 EDT
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Sat, 14 Apr 90 03:36:34 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa01688;
14 Apr 90 3:16 EDT
Message-Id: <DIGEST.184.900414.021131.10@MC.LCS.MIT.EDU>
Date: 14 Apr 90 02:11:30 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #346
Scheme Digest #346 14 Apr 90 02:11:30 EDT
Today's Topics:
Portable object oriented scheme systems (2 messages)
----------------------------------------------------------------------
Message-ID: <1990Apr12.104628.11596@nada.kth.se>
Date: 12 Apr 90 10:46:28 GMT
From: Johan Ihren <snorkelwacker!usc!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!kth.se!draken!johani@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: Portable object oriented scheme systems
In article <RAIBLE.90Apr10173310@ew09.nas.nasa.gov> raible@orville.nas.nasa.gov writes:
>
>I'm interested in any portable object oriented systems for scheme, or
>a non-portable one based on xscheme.
Our SCIX system (an OO interface between Scheme and the X Window System)
has a nice object oriented system, designed by Magnus Persson, Digital,
in it. It supports muliple inheritance, inheritance of instances (i.e. not
just of classes), dynamic insertion, deletion and renaming of methods,
optional per-method resolution of message name collisions and other things
one might expect from an OO system.
It is perfectly possible to use HWOOPS separately from SCIX. The only thing
needed is the extend-syntax macro mechanism available in some Scheme systems
(notably Chez Scheme). The source to extend-syntax has been made freely
available by its author, Kent Dybvig, and therefore it has been ported to
several Scheme systems without native extend-syntax support. We have ported
it to the Scheme->C system ourselves. We designed HWOOPS with extend-syntax
and then built SCIX upon HWOOPS.
The HWOOPS subsystem is available in the SCIX distribution which can be
found on expo.lcs.mit.edu:~ftp/contrib/scix-0.96.tar.Z. All you really need
is a few files, but there is no separate distribution of HWOOPS right now.
Of course it is also possible to get it directly through me.
Johan Ihren
Dept. of Computer Science,
Royal Institute of Technology, Stockholm, Sweden
Email: johani@nada.kth.se -or- <backbone>!sunic!nada!johani
------------------------------
Message-ID: <1990Apr12.110110.12398@nada.kth.se>
Date: 12 Apr 90 11:01:10 GMT
From: Johan Ihren <eru!luth!sunic!kth.se!draken!johani@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: Portable object oriented scheme systems
In article <RAIBLE.90Apr10173310@ew09.nas.nasa.gov> raible@orville.nas.nasa.gov writes:
>
>I'm interested in any portable object oriented systems for scheme, or
>a non-portable one based on xscheme.
>
Our SCIX system (an OO interface between Scheme and the X Window System)
has a nice object oriented system, designed by Magnus Persson, Digital,
in it. It supports muliple inheritance, inheritance of instances (i.e. not
just of classes), dynamic insertion, deletion and renaming of methods,
optional per-method resolution of messagename collisions and other things
one might expect from an OO system.
It is perfectly possible to use HWOOPS separately from SCIX. The only thing
needed is the extend-syntax macro mechanism available in some Scheme systems
(notably Kent Dybvig's Chez Scheme). As Kent Dybvig has made the Scheme source
to extend-syntax freely available it has been ported to othre Scheme systems
as well. We have ported it to the Scheme->C system, designed HWOOPS with
extend-syntax and then built SCIX upon HWOOPS.
The HWOOPS subsystem is available in the SCIX distribution which can be
found on expo.lcs.mit.edu:~ftp/contrib/scix-0.96.tar.Z. All you really need
is a few files, but there is no separate distribution of HWOOPS right now.
Of course it is also possible to get it directly from me.
Johan Ihren
Dept. of Computer Science,
Royal Institute of Technology, Stockholm, Sweden
Email: johani@nada.kth.se -or- <backbone>!sunic!nada!johani
------------------------------
End of Scheme Digest
********************
∂17-Apr-90 0150 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #347
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 17 Apr 90 01:49:51 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA13644; Tue, 17 Apr 90 04:47:36 EDT
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Tue, 17 Apr 90 04:45:40 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa26905;
17 Apr 90 3:13 EDT
Message-Id: <DIGEST.184.900417.022642.20@MC.LCS.MIT.EDU>
Date: 17 Apr 90 02:26:42 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #347
Scheme Digest #347 17 Apr 90 02:26:42 EDT
Today's Topics:
Forward Chaining?
----------------------------------------------------------------------
Message-ID: <134442@sun.Eng.Sun.COM>
Date: 13 Apr 90 20:39:35 GMT
From: Michael Ginn <neon-tetra!ginn@sun.com>
To: scheme@mc.lcs.mit.edu
Subject: Forward Chaining?
Has anyone developed systems for doing powerful, efficient forward chaining in
Scheme, either commercially or otherwise? This is important because some
people have claimed that Scheme can't do it and I would like to use Scheme if
possible.
I will summarize the results...
---Michael Ginn
ryan@sun.com
------------------------------
End of Scheme Digest
********************
∂18-Apr-90 0018 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #348
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 18 Apr 90 00:18:02 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02759; Wed, 18 Apr 90 03:11:47 EDT
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Wed, 18 Apr 90 03:09:52 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa18640;
18 Apr 90 2:55 EDT
Message-Id: <DIGEST.184.900418.021154.26@MC.LCS.MIT.EDU>
Date: 18 Apr 90 02:11:53 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #348
Scheme Digest #348 18 Apr 90 02:11:53 EDT
Today's Topics:
MIT scheme debugger
----------------------------------------------------------------------
Message-ID: <JGABRIEL.90Apr16205703@mtecv2.mty.itesm.mx>
Date: 17 Apr 90 02:57:03 GMT
From: Juan Gabriel Ruiz Pinto <samsung!cs.utexas.edu!mtecv2!mtecv2.mty.itesm.mx!jgabriel@think.com>
To: scheme@mc.lcs.mit.edu
Subject: MIT scheme debugger
Hello,
I'm using MIT scheme v7.0, and I don't have the debugger's documentation.
Can any body send me a short explanation about the use of the scheme
debugger, or where can I get the documentation (I'm looking for texinfo
or man pages) I don't have TEX.
Thank's for your help!
--
***** Greetings from Mexico !! *****
Juan Gabriel Ruiz Pinto Internet:
Ing. Sistemas Electronicos jgabriel@mtecv2.mty.itesm.mx
I.T.E.S.M. Campus Monterrey
--
***** Greetings from Mexico !! *****
Juan Gabriel Ruiz Pinto Internet:
Ing. Sistemas Electronicos jgabriel@mtecv2.mty.itesm.mx
I.T.E.S.M. Campus Monterrey
------------------------------
End of Scheme Digest
********************
∂19-Apr-90 0024 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #349
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 19 Apr 90 00:24:41 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA04702; Thu, 19 Apr 90 03:20:57 EDT
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Thu, 19 Apr 90 03:19:03 edt
Received: by mintaka.lcs.mit.edu id aa11583; 19 Apr 90 3:08 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa11418;
19 Apr 90 3:01 EDT
Message-Id: <DIGEST.184.900419.024150.6@MC.LCS.MIT.EDU>
Date: 19 Apr 90 02:41:49 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #349
Scheme Digest #349 19 Apr 90 02:41:49 EDT
Today's Topics:
Query about David Betz' XScheme.
portable non-printing object
----------------------------------------------------------------------
Message-ID: <1990Apr18.154617.27649@athena.mit.edu>
Date: Wed, 18 Apr 90 15:46:17 GMT
From: David R Kohr <news@mc.lcs.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Query about David Betz' XScheme.
I have Version 0.16 of David Betz' XScheme, a version of Scheme with
object-oriented extensions (David Betz is the author of XLisp). This
version dates from January, 1989. Is there a newer version of
XScheme available? In particular, I was wondering if the documentation
has been updated; the current documentation gives virtually no
information about how to use the object-oriented extensions. Also,
the machine-specific interface code doesn't do much more than file
I/O; XLisp for the PC had primitives for doing graphics, among other
things. If there is a newer version, where could I find it?
Thanks,
--
David R. Kohr M.I.T. Lincoln Laboratory Group 45 ("Radars 'R' Us")
email: DRK@ATHENA.MIT.EDU (preferred) or KOHR@LL.LL.MIT.EDU
phone: (617)981-0775 (work) or (617)527-3908 (home)
------------------------------
Message-ID: <RAIBLE.90Apr18180254@ew09.nas.nasa.gov>
Date: 19 Apr 90 01:02:54 GMT
From: "Eric L. &" <amelia!raible@AMES.ARC.NASA.GOV>
To: scheme@mc.lcs.mit.edu
Subject: portable non-printing object
Is the following portable? I can't find anything in R3.99RS that says
it's not:
(define *the-non-printing-object* (string->symbol ""))
I realize that some implementations might actually print something out
(i.e. ||), but are there any non-portable ramifications of having a
zero-length symbol?
- Eric
------------------------------
End of Scheme Digest
********************
∂19-Apr-90 2334 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #350
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 19 Apr 90 23:34:33 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA23712; Fri, 20 Apr 90 02:32:39 EDT
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Fri, 20 Apr 90 02:30:45 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa02375;
20 Apr 90 2:30 EDT
Message-Id: <DIGEST.184.900420.022654.12@MC.LCS.MIT.EDU>
Date: 20 Apr 90 02:26:54 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #350
Scheme Digest #350 20 Apr 90 02:26:54 EDT
Today's Topics:
portable non-printing object
----------------------------------------------------------------------
Message-ID: <3108@goanna.cs.rmit.OZ.AU>
Date: 20 Apr 90 00:50:31 GMT
From: Richard O'keefe <snorkelwacker!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!goanna!ok@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: portable non-printing object
In article <RAIBLE.90Apr18180254@ew09.nas.nasa.gov>, raible@nas.nasa.gov (Eric L. &) writes:
> (define *the-non-printing-object* (string->symbol ""))
> I realize that some implementations might actually print something out
In T, I get
> (define *foo* (string->symbol ""))
\c
that is, (string->symbol "") prints as a backslash followed by a lower-case c
------------------------------
End of Scheme Digest
********************
∂20-Apr-90 0704 @zurich.ai.mit.edu,@MC.lcs.mit.edu,@uicsrd.csrd.uiuc.edu:harrison@sp21.csrd.uiuc.edu tail recursion
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 20 Apr 90 07:03:56 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA27273; Fri, 20 Apr 90 09:59:11 EDT
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Fri, 20 Apr 90 09:57:23 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa17456;
20 Apr 90 9:55 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 20 Apr 90 09:54:57 EDT
Received: from uicsrd.csrd.uiuc.edu by mintaka.lcs.mit.edu id aa17243;
20 Apr 90 9:49 EDT
Received: from sp21.csrd.uiuc.edu by uicsrd.csrd.uiuc.edu with SMTP
(5.61+/IDA-1.2.8) id AA15451; Fri, 20 Apr 90 08:49:25 -0500
Received: by sp21.csrd.uiuc.edu. (4.0/SMI-4.0)
id AA01128; Fri, 20 Apr 90 08:49:22 CDT
Date: Fri, 20 Apr 90 08:49:22 CDT
From: Luddy Harrison <harrison@sp21.csrd.uiuc.edu>
Message-Id: <9004201349.AA01128@sp21.csrd.uiuc.edu.>
To: rrrs-authors@mc.lcs.mit.edu
Subject: tail recursion
What precisely is meant by "properly tail-recursive"? That is, what
is required of an implementation, in order that it may be called
properly tail-recursive?
-Luddy Harrison
∂20-Apr-90 1249 dyb@iuvax.cs.indiana.edu Re: tail recursion
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 20 Apr 90 12:47:33 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA03812; Fri, 20 Apr 90 15:35:31 EDT
Received: from iuvax.cs.indiana.edu (iuvax.cs.indiana.edu) by zurich.ai.mit.edu; Fri, 20 Apr 90 15:33:30 edt
Message-Id: <9004201933.AA23548@zurich.ai.mit.edu>
Received: by iuvax.cs.indiana.edu
Date: Fri, 20 Apr 90 14:34:47 -0500
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
To: rrrs-authors@zurich.ai.mit.edu
Subject: Re: tail recursion
> Date: Fri, 20 Apr 90 08:49:22 CDT
> From: Luddy Harrison <harrison@sp21.csrd.uiuc.edu>
>
> What precisely is meant by "properly tail-recursive"? That is, what
> is required of an implementation, in order that it may be called
> properly tail-recursive?
How about this:
The net (modulo storage reclamation) amount of storage space consumed
by performing any sequence of tail calls p1 => p2 => ... => pn is no
more than the amount that would be consumed by performing a direct tail
call from p1 => pn.
A tail call is a procedure call occurring in "tail position".
For a lambda expression of the form (lambda formals e1 ... e2), e2 is
in tail position.
If a conditional expression of the form (if e1 e2 e3) is in tail
position, then e2 and e3 are in tail position.
If a conditional expression of the form (if e1 e2) is in tail position,
then e2 is in tail position.
A subexpression of a derived expression type is in tail position if
the derived expression is in tail position and the subexpression occurs
in tail position in the expansion of the derived expression.
Example:
The following program should not cause a memory overflow (assuming that
garbage closures created along the way are reclaimed):
(define f (lambda (f) (lambda () ((f f)))))
((f f))
This example demonstrates why it is necessary to think in terms of tail
"calls", not tail "recursion".
Kent
∂20-Apr-90 1328 RPG@sail.stanford.edu re: tail recursion
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 20 Apr 90 13:28:15 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA04782; Fri, 20 Apr 90 16:18:40 EDT
Received: from SAIL.Stanford.EDU (sail.stanford.edu) by zurich.ai.mit.edu; Fri, 20 Apr 90 16:16:50 edt
Message-Id: <dLqZX@SAIL.Stanford.EDU>
Date: 20 Apr 90 1316 PDT
From: Dick Gabriel <RPG@sail.stanford.edu>
Subject: re: tail recursion
To: dyb@iuvax.cs.indiana.edu, rrrs-authors@zurich.ai.mit.edu
[In reply to message from dyb@iuvax.cs.indiana.edu sent Fri, 20 Apr 90 14:34:47 -0500.]
I'm not sure it's a well-defined term.
How about this:
The net (modulo storage reclamation) amount of storage space consumed
by performing any sequence of tail calls p1 => p2 => ... => pn is no
more than the amount that would be consumed by performing a direct tail
call from p1 => pn.
What if the storage space for p1 => ... => pn is the space needed for p1
=> pn + 1? +k? *k? What if it's arbitrarily large, but all infinite tail
call programs loop forever with the right behavior? How would you test
whether an implementation had this property?
Scheme requires iteration through function call. Other lanaguages have
restrictions on the size of iteration (oh? Consider they cannot be larger
than indexes for those machines.) If my implementation has other
restrictions based on size, why shouldn't this be one of them, especially
if you cannot verify the property *without* looking at the implementation
source?
I've mentioned before that this requirement might prevent certain
implementation choices. For example, a hardware vendor has told me that in
n years, it will support only languages in the ``mainstream'' where
mainstream means that these languages use their common backend. Other
vendors have said the same thing. I am in the process of determining
whether I can convince their compiler backend guys to support tail call
optimizations. If I cannot, I don't have a viable Common Lisp for that
system, because the implementation requires it. Are you so happy to put
Scheme out of the mainstream for that vendor?
Well, of course you are, because you wouldn't be Scheme-heads otherwise!
(I don't know how to make a smiley face with ASCII characters, so here's a
duck instead. Please take it as a smiley face:
________
| Quack? |
--------
_ /
/@@____ _ /
| ____]
\ / /
\------/ /
\ << /
\____/
| |
<]<]
)
-rpg-
∂20-Apr-90 1338 harrison@sp21.csrd.uiuc.edu tail recursion
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 20 Apr 90 13:37:50 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA04820; Fri, 20 Apr 90 16:20:06 EDT
Received: from uicsrd.csrd.uiuc.edu ([128.174.132.2]) by zurich.ai.mit.edu; Fri, 20 Apr 90 16:18:12 edt
Received: from sp21.csrd.uiuc.edu by uicsrd.csrd.uiuc.edu with SMTP
(5.61+/IDA-1.2.8) id AA29698; Fri, 20 Apr 90 15:19:30 -0500
Received: by sp21.csrd.uiuc.edu. (4.0/SMI-4.0)
id AA01467; Fri, 20 Apr 90 15:19:24 CDT
Date: Fri, 20 Apr 90 15:19:24 CDT
From: harrison@sp21.csrd.uiuc.edu (Luddy Harrison)
Message-Id: <9004202019.AA01467@sp21.csrd.uiuc.edu.>
To: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: R. Kent Dybvig's message of Fri, 20 Apr 90 14:34:47 -0500 <9004201933.AA23548@zurich.ai.mit.edu>
Subject: tail recursion
> The net (modulo storage reclamation) amount of storage space consumed
> by performing any sequence of tail calls p1 => p2 => ... => pn is no
> more than the amount that would be consumed by performing a direct tail
> call from p1 => pn.
This would mean that if I implemented the tail call from p1 => pn in a
very space-consumptive way, that it would be ok to do the same for the
sequence p1 => p2 => ... => pn; but that if I handled p1 => pn nicely,
I would be required to do the same for p1 => p2 => ... => pn.
> The following program should not cause a memory overflow (assuming that
> garbage closures created along the way are reclaimed):
> (define f (lambda (f) (lambda () ((f f)))))
> ((f f))
This doesn't follow from the above characterization of tail-recursion,
but it could serve as an alternate definition I guess. If my
implementation ran this program without overflowing, then it would be
tail-recursive, even if it didn't handle other tail-recursive programs
in the expected way.
??
∂20-Apr-90 1417 feeley@chaos.cs.brandeis.edu tail recursion
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 20 Apr 90 14:17:22 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA05715; Fri, 20 Apr 90 17:08:08 EDT
Received: from chaos.cs.brandeis.edu (chaos.cs.brandeis.edu) by zurich.ai.mit.edu; Fri, 20 Apr 90 17:06:17 edt
Received: by chaos.cs.brandeis.edu Fri, 20 Apr 90 17:08:05 edt
Date: Fri, 20 Apr 90 17:08:05 edt
From: "Marc Feeley" <feeley@chaos.cs.brandeis.edu>
Message-Id: <9004202108.AA00809@chaos.cs.brandeis.edu>
To: rrrs-authors@zurich.ai.mit.edu
Subject: tail recursion
To me, tail call optimization is just one of the many techniques a
Scheme implementation can have. I see no reason to impose it on all
implementations.
If I had a Scheme implementation running on a Turing machine (or other
machine with more memory (real or virtual) than you can use in a
lifetime) and this implementation did not have what you and I call
tail recursion optimization, could you tell the difference?
If we can't define the term precisely, why not just remove the
`properly tail-recursive' requirement from Scheme and thus leave this
issue to the common sense of the implementor (just like having
negative numbers is up to the implementor!).
Marc
∂20-Apr-90 1448 jar@zurich.ai.mit.edu tail recursion
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 20 Apr 90 14:48:30 PDT
Received: from zurich.ai.mit.edu (VOID.AI.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA06292; Fri, 20 Apr 90 17:39:38 EDT
Received: from localhost by zurich.ai.mit.edu; Fri, 20 Apr 90 17:37:46 edt
Date: Fri, 20 Apr 90 17:37:46 edt
From: jar@zurich.ai.mit.edu (Jonathan Rees)
Message-Id: <9004202137.AA24016@zurich.ai.mit.edu>
To: feeley@chaos.cs.brandeis.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: "Marc Feeley"'s message of Fri, 20 Apr 90 17:08:05 edt <9004202108.AA00809@chaos.cs.brandeis.edu>
Subject: tail recursion
Date: Fri, 20 Apr 90 17:08:05 edt
From: "Marc Feeley" <feeley@chaos.cs.brandeis.edu>
If we can't define the term precisely, why not just remove the
`properly tail-recursive' requirement from Scheme and thus leave this
issue to the common sense of the implementor (just like having
negative numbers is up to the implementor!).
Tail-call optimization should have exactly the same status (present or
absent) in the language definition as garbage collection, which might
be called "cons optimization". Tail-call optimization is really just
a special kind of garbage collection, with the same wide spectrum of
implementation choices -- stop and copy, compacting, incremental,
compile-time, etc. E.g. if your target architecture really has no way
to express tail calls, then you might choose to just wait until a
stack overflow occurs and squeeze out useless stack frames at that
point.
∂20-Apr-90 1509 feeley@chaos.cs.brandeis.edu tail recursion
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 20 Apr 90 15:08:57 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA06666; Fri, 20 Apr 90 18:01:57 EDT
Received: from chaos.cs.brandeis.edu (chaos.cs.brandeis.edu) by zurich.ai.mit.edu; Fri, 20 Apr 90 18:00:00 edt
Received: by chaos.cs.brandeis.edu Fri, 20 Apr 90 18:01:49 edt
Date: Fri, 20 Apr 90 18:01:49 edt
From: "Marc Feeley" <feeley@chaos.cs.brandeis.edu>
Message-Id: <9004202201.AA05123@chaos.cs.brandeis.edu>
To: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Jonathan Rees's message of Fri, 20 Apr 90 17:37:46 edt <9004202137.AA24016@zurich.ai.mit.edu>
Subject: tail recursion
> Tail-call optimization should have exactly the same status (present or
> absent) in the language definition as garbage collection, which might
> be called "cons optimization". Tail-call optimization is really just
> a special kind of garbage collection, ...
I agree. Is there any mention of `garbage collection' in the standard?
Marc
∂20-Apr-90 1603 mkatz@garlic.stanford.edu tail recursion
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 20 Apr 90 16:03:01 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA07384; Fri, 20 Apr 90 18:53:23 EDT
Received: from garlic.Stanford.EDU ([36.22.0.43]) by zurich.ai.mit.edu; Fri, 20 Apr 90 18:51:32 edt
Received: by garlic.Stanford.EDU (5.57/Ultrix3.0-C)
id AA07495; Fri, 20 Apr 90 15:48:16 PDT
Date: Fri, 20 Apr 90 15:48:16 PDT
From: mkatz@garlic.stanford.edu (Morris Katz)
Message-Id: <9004202248.AA07495@garlic.Stanford.EDU>
To: RPG@sail.stanford.edu
Cc: dyb@iuvax.cs.indiana.edu, rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Dick Gabriel's message of 20 Apr 90 1316 PDT <dLqZX@SAIL.Stanford.EDU>
Subject: tail recursion
Date: 20 Apr 90 1316 PDT
From: Dick Gabriel <RPG@sail.stanford.edu>
[In reply to message from dyb@iuvax.cs.indiana.edu sent Fri, 20 Apr 90 14:34:47 -0500.]
I'm not sure it's a well-defined term.
Based on previous discussion with Luddy, I know that this is exactly the point
he is trying to make. His real question is how can one define tail recursion
without appealing to a specific type of computer architecture. What would it
mean for Scheme to be or not to be tail recursive on some novel architecture
which doesn't even have stacks, etc. Is there some way that the characteristic
which is desired can be specified through semantics rather than implementation?
-------------------------------------------------------------------------------
Morry Katz
katz@cs.stanford.edu
-------------------------------------------------------------------------------
∂20-Apr-90 1805 gyro@cymbal.reasoning.com tail recursion
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 20 Apr 90 18:04:57 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA08996; Fri, 20 Apr 90 20:54:25 EDT
Received: from drums.reasoning.com (reasoning.com) by zurich.ai.mit.edu; Fri, 20 Apr 90 20:52:32 edt
Received: from cymbal.reasoning.com by drums.reasoning.com with SMTP (5.61/25-eef)
id AA06573; Fri, 20 Apr 90 17:54:04 -0700
for rrrs-authors@zurich.ai.mit.edu
Received: by cymbal.reasoning.com. (4.0/SMI-4.0)
id AA06245; Fri, 20 Apr 90 17:44:05 PDT
Date: Fri, 20 Apr 90 17:44:05 PDT
Message-Id: <9004210044.AA06245@cymbal.reasoning.com.>
From: Gyro@reasoning.com
Sender: gyro@cymbal.reasoning.com
To: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Morris Katz's message of Fri, 20 Apr 90 15:48:16 PDT <9004202248.AA07495@garlic.Stanford.EDU>
Subject: tail recursion
Date: Fri, 20 Apr 90 15:48:16 PDT
From: mkatz@garlic.stanford.edu (Morris Katz)
Date: 20 Apr 90 1316 PDT
From: Dick Gabriel <RPG@sail.stanford.edu>
[In reply to message from dyb@iuvax.cs.indiana.edu sent Fri, 20 Apr 90 14:34:47 -0500.]
I'm not sure it's a well-defined term.
Based on previous discussion with Luddy, I know that this is exactly the point
he is trying to make. His real question is how can one define tail recursion
without appealing to a specific type of computer architecture. What would it
mean for Scheme to be or not to be tail recursive on some novel architecture
which doesn't even have stacks, etc. Is there some way that the characteristic
which is desired can be specified through semantics rather than implementation?
No, of course not. It's not a semantic property; it's an implementation
property. As Jonathan Rees points out, it is a concept closely related to
garbage collection, the presence of which is also an implementation property,
not a semantic one. Both of these implementation properties have indirect
semantic consequences, however, in that they make it possible *in practice* to
write programs in a certain style which some people like; without these
properties, the execution of programs written in that style would make (what is
judged to be) inadequately effective use of the hardware resources available.
Would they be considered important on every imaginable architecture? Who knows?
-- Scott
∂20-Apr-90 2349 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #351
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 20 Apr 90 23:49:36 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA12697; Sat, 21 Apr 90 02:43:39 EDT
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Sat, 21 Apr 90 02:41:45 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa29230;
21 Apr 90 2:34 EDT
Message-Id: <DIGEST.184.900421.021157.17@MC.LCS.MIT.EDU>
Date: 21 Apr 90 02:11:57 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #351
Scheme Digest #351 21 Apr 90 02:11:57 EDT
Today's Topics:
portable non-printing object
Scheme for the apollo
----------------------------------------------------------------------
Message-ID: <DUCHIER.90Apr19235346@albania.cs.yale.edu>
Date: 20 Apr 90 03:53:46 GMT
From: Denys Duchier <cs.yale.edu!newsbase!duchier@yale-zoo.arpa>
To: scheme@mc.lcs.mit.edu
Subject: Re: portable non-printing object
In article <3108@goanna.cs.rmit.OZ.AU> ok@goanna.cs.rmit.OZ.AU (Richard O'keefe) writes:
> In article <RAIBLE.90Apr18180254@ew09.nas.nasa.gov>, raible@nas.nasa.gov (Eric L. &) writes:
> > (define *the-non-printing-object* (string->symbol ""))
>
> > I realize that some implementations might actually print something out
>
> In T, I get
> > (define *foo* (string->symbol ""))
> \c
> that is, (string->symbol "") prints as a backslash followed by a lower-case c
Funny! I just tried this in T3.1 and I get:
> (define *foo* (string->symbol ""))
\
which is a backslash followed by a null character (control @). If you
really want a non printing object in T, try this:
(define *the-non-printing-object*
(object '#f ((print self stream) (return))))
Hey! this worked! My first bit of code in T for umpteen years, and it
worked... ahem!
--Denys
------------------------------
Message-ID: <9004201547.AA27357@mtecv2.mty.itesm.mx>
Date: Fri, 20 Apr 90 09:47:32 CST
From: Juan Gabriel Ruiz Pinto <jgabriel@mtecv2.mty.itesm.mx>
To: Scheme@lcs.mit.edu
Subject: Scheme for the apollo
I'm looking for some special scheme for a work station Apollo,
anybody can help me to found one?
Thank's in advance!
***** Greetings from Mexico! *****
Juan Gabriel Ruiz Pinto Internet:
Ing. Sistemas Electronicos jgabriel@mtecv2.mty.itesm.mx
I.T.E.S.M. Campus Monterrey
------------------------------
End of Scheme Digest
********************
∂21-Apr-90 0731 jinx@zurich.ai.mit.edu tail recursion
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Apr 90 07:31:33 PDT
Received: from zurich.ai.mit.edu (CHAMARTIN.AI.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA15006; Sat, 21 Apr 90 10:24:37 EDT
Received: from localhost by zurich.ai.mit.edu; Sat, 21 Apr 90 10:22:56 edt
Date: Sat, 21 Apr 90 10:22:56 edt
From: jinx@zurich.ai.mit.edu (Guillermo J. Rozas)
Message-Id: <9004211422.AA29626@zurich.ai.mit.edu>
To: Gyro@reasoning.com
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Gyro@Reasoning.COM's message of Fri, 20 Apr 90 17:44:05 PDT <9004210044.AA06245@cymbal.reasoning.com.>
Subject: tail recursion
Reply-To: jinx@zurich.ai.mit.edu
No, of course not. It's not a semantic property; it's an
implementation property. As Jonathan Rees points out, it is a
concept closely related to garbage collection, the presence of
which is also an implementation property, not a semantic one.
Both of these implementation properties have indirect semantic
consequences, however, in that they make it possible *in practice*
to write programs in a certain style which some people like;
without these properties, the execution of programs written in
that style would make (what is judged to be) inadequately
effective use of the hardware resources available. Would they be
considered important on every imaginable architecture? Who knows?
I don't agree with you. You can have semantics at different levels,
depending only on how much magnification you want out of the semantics
microscope. It should not be hard to write a semantics with explicit
memory management where both of these properties are explicit. Of
course, the semantics would be (in most ways) much less informative
than the usual semantics that ignores such aspects.
The way that I like to define proper tail recursion is as follows:
An evaluator with explicit control and finite-memory management that
implements "proper tail recursion" can be written for the language.
It can be similar to the one in chapter 5 of SICP, although it does
not have to be written in machine language, but can be written on any
mutually acceptable language, such as Scheme, C, or denotational
semantics. Call such an implementation (definition) M0.
An implementation M of the language is properly tail-recursive if
there exists a constant K (dependent only on M), such that any program
running on M requires at most K times the amount of storage that the
same program would require to run on M0 (for the same inputs/state,
etc.).
By requiring X storage I mean that if the implementation is given X
units of storage, an out-of-memory condition does not arise during the
execution of the program.
I realize that this definition has implications for the implementation
of environment structure, closures, etc., but that is precisely the
point.
Furthermore, if an implementation has infinite memory, no
out-of-memory conditions can arise, so you can't ever tell whether or
not it is properly tail recursive, but it shouldn't matter either.
∂22-Apr-90 0052 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #352
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Apr 90 00:52:40 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA22631; Sun, 22 Apr 90 03:50:12 EDT
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Sun, 22 Apr 90 03:48:19 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa17530;
22 Apr 90 3:37 EDT
Message-Id: <DIGEST.184.900422.031159.21@MC.LCS.MIT.EDU>
Date: 22 Apr 90 03:11:59 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #352
Scheme Digest #352 22 Apr 90 03:11:59 EDT
Today's Topics:
MultiScheme programs
Scheme for the apollo
----------------------------------------------------------------------
Message-ID: <38100003@m.cs.uiuc.edu>
Date: 20 Apr 90 20:04:00 GMT
From: ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!m.cs.uiuc.edu!jfernand@iuvax.cs.indiana.edu
To: scheme@mc.lcs.mit.edu
Subject: MultiScheme programs
Greetings,
Does anyone out there have any test/benchmark programs
(preferably in electronic form) for MultiLISP, MultiScheme, or
Mul-T? Or references to such?
Thanks,
Jose R. Fernandez
jfernand@cs.uiuc.edu
------------------------------
Message-ID: <7596@ubc-cs.UUCP>
Date: 21 Apr 90 19:41:44 GMT
From: Vincent Manis <ubc-cs!manis@beaver.cs.washington.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: Scheme for the apollo
Chez Scheme (Cadence Research Systems, Inc., 812 333-9269) runs very
nicely on Apollo DN3000/DN3500's. I don't believe they have, or intend
to have, a Prism (DN10000) port. Cost is US$450/copy for academic sites,
with generous site licencing. You could contact Kent Dybvig
<dyb@iuvax.cs.indiana.edu> at Cadence for more info.
I have no connection with Cadence, except as a customer.
--
\ Vincent Manis <manis@cs.ubc.ca> "There is no law that vulgarity and
\ Department of Computer Science literary excellence cannot coexist."
/\ University of British Columbia -- A. Trevor Hodge
/ \ Vancouver, BC, Canada V6T 1W5 (604) 228-2394
------------------------------
End of Scheme Digest
********************
∂23-Apr-90 0847 harrison@sp21.csrd.uiuc.edu tail recursion
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Apr 90 08:47:01 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA06019; Mon, 23 Apr 90 11:36:40 EDT
Received: from uicsrd.csrd.uiuc.edu ([128.174.162.2]) by zurich.ai.mit.edu; Mon, 23 Apr 90 11:34:47 edt
Received: from sp21.csrd.uiuc.edu by uicsrd.csrd.uiuc.edu with SMTP
(5.61+/IDA-1.2.8) id AA22027; Mon, 23 Apr 90 10:36:06 -0500
Received: by sp21.csrd.uiuc.edu. (4.0/SMI-4.0)
id AA03558; Mon, 23 Apr 90 10:36:01 CDT
Date: Mon, 23 Apr 90 10:36:01 CDT
From: harrison@sp21.csrd.uiuc.edu (Luddy Harrison)
Message-Id: <9004231536.AA03558@sp21.csrd.uiuc.edu.>
To: jinx@zurich.ai.mit.edu, rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Guillermo J. Rozas's message of Sat, 21 Apr 90 10:22:56 edt <9004211422.AA29626@zurich.ai.mit.edu>
Subject: tail recursion
>> An implementation M of the language is properly tail-recursive if
>> there exists a constant K (dependent only on M), such that any program
>> running on M requires at most K times the amount of storage that the
>> same program would require to run on M0 (for the same inputs/state,
>> etc.).
>> By requiring X storage I mean that if the implementation is given X
>> units of storage, an out-of-memory condition does not arise during the
>> execution of the program.
Suppose that I implement Scheme for a dataflow machine, or for another
machine in which there is no notion of "storage". (I would argue that
as complex as the memory systems of modern machines are becoming, this
is not as far-fetched as it might seem.) It might be quite difficult
to make an analogy between M0 and my implementation.
>>I don't agree with you. You can have semantics at different levels,
>>depending only on how much magnification you want out of the semantics
>>microscope. It should not be hard to write a semantics with explicit
>>memory management where both of these properties are explicit. Of
>>course, the semantics would be (in most ways) much less informative
>>than the usual semantics that ignores such aspects.
I disagree; the problem with a more operational semantics is not that
it is less informative, but precisely that it is too informative; that
is, it overspecifies the meaning of programs. A (more nearly) fully
abstract semantics has the advantage of giving a "minimal"
characterization of program meanings, without resort to notions of
stacks, heaps, program counters, etc.
-Luddy Harrison
∂23-Apr-90 1224 jinx@zurich.ai.mit.edu tail recursion
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Apr 90 12:23:48 PDT
Received: from zurich.ai.mit.edu (CHAMARTIN.AI.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA10151; Mon, 23 Apr 90 15:13:40 EDT
Received: from localhost by zurich.ai.mit.edu; Mon, 23 Apr 90 15:11:49 edt
Date: Mon, 23 Apr 90 15:11:49 edt
From: jinx@zurich.ai.mit.edu (Guillermo J. Rozas)
Message-Id: <9004231911.AA20446@zurich.ai.mit.edu>
To: harrison@sp21.csrd.uiuc.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Luddy Harrison's message of Mon, 23 Apr 90 10:36:01 CDT <9004231536.AA03558@sp21.csrd.uiuc.edu.>
Subject: tail recursion
Reply-To: jinx@zurich.ai.mit.edu
Suppose that I implement Scheme for a dataflow machine, or for another
machine in which there is no notion of "storage". (I would argue that
as complex as the memory systems of modern machines are becoming, this
is not as far-fetched as it might seem.) It might be quite difficult
to make an analogy between M0 and my implementation.
However you map my definition into the resource model for your machine
there are still two possibilities:
- Your implementation never runs out of resources (I find this hard to
believe). Since I can't tell the difference between your
implementation and a properly tail-recursive one, the issue is moot.
- Your machine can run out of resources. Then the requirement imposes
that the mapping between your resources and M0 be such that the
resource requirement is at worst linear with respect to the storage
requirement of M0. If your implementation doesn't do this, then it is
not a real Scheme. Call it non-tail-recursive-scheme, or whatever,
and I may even like it and use it, but it is not Scheme (as currently
defined).
A deeper question is whether Scheme (with it's applicative semantics
and imperative constructs, etc.) is an appropriate language for such a
machine. You may find that tail recursion is not the problem, but the
whole model of the language, and that you have to scrap it then.
Until parallelism is understood better, I don't think you'll be able
to convince me that such a restriction is better or worse than any
other (such as the restrictions imposed by applicative order
evaluation).
I disagree; the problem with a more operational semantics is not that
it is less informative, but precisely that it is too informative; that
is, it overspecifies the meaning of programs. A (more nearly) fully
abstract semantics has the advantage of giving a "minimal"
characterization of program meanings, without resort to notions of
stacks, heaps, program counters, etc.
All semantics are just restrictions on how an implementation of the
language may not behave. How much you want to restrict it or not is a
matter of style or taste.
I think that the definition that I sent is valid, but you don't like
it. On the other hand, I think that what you really don't like is the
restriction, not the way in which I phrased it. We can argue forever
on whether it is a good restriction or not, but perhaps we can agree
on what the restriction is interpreted to mean, which is what I
thought your original question was about.
∂23-Apr-90 1316 harrison@sp21.csrd.uiuc.edu tail recursion
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Apr 90 13:16:32 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA11126; Mon, 23 Apr 90 16:08:02 EDT
Received: from uicsrd.csrd.uiuc.edu ([128.174.162.2]) by zurich.ai.mit.edu; Mon, 23 Apr 90 16:05:23 edt
Received: from sp21.csrd.uiuc.edu by uicsrd.csrd.uiuc.edu with SMTP
(5.61+/IDA-1.2.8) id AA01738; Mon, 23 Apr 90 15:06:18 -0500
Received: by sp21.csrd.uiuc.edu. (4.0/SMI-4.0)
id AA03672; Mon, 23 Apr 90 15:06:14 CDT
Date: Mon, 23 Apr 90 15:06:14 CDT
From: harrison@sp21.csrd.uiuc.edu (Luddy Harrison)
Message-Id: <9004232006.AA03672@sp21.csrd.uiuc.edu.>
To: jinx@zurich.ai.mit.edu, rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Guillermo J. Rozas's message of Mon, 23 Apr 90 15:11:49 edt <9004231911.AA20446@zurich.ai.mit.edu>
Subject: tail recursion
>> I think that what you really don't like is the restriction, not the
>> way in which I phrased it.
Nonsense; don't kill the fun by making this personal. I simply want for
you to tell me what it means without inadvertantly ruling out whole
classes of machines and implementations.
Consider my dataflow example again. It may be that in order to
achieve speedup, such a machine uses a quantity of "resources" that is
not O(kX) where X is the consumption of M0. Is it desirable to define
such an implementation to be in violation of the standard? Many
implementation styles trade space for speed, parallel implementations
among them; your definition of proper tail-recursion appears to
disallow this.
-Luddy Harrison
∂23-Apr-90 1357 markf@zurich.ai.mit.edu Re: tail recursion
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Apr 90 13:57:02 PDT
Received: from zurich.ai.mit.edu (MONTREUX.AI.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA11796; Mon, 23 Apr 90 16:49:53 EDT
Received: from localhost by zurich.ai.mit.edu; Mon, 23 Apr 90 16:47:48 edt
Message-Id: <9004232047.AA21460@zurich.ai.mit.edu>
To: harrison@sp21.csrd.uiuc.edu (Luddy Harrison)
Cc: jinx@zurich.ai.mit.edu, rrrs-authors@zurich.ai.mit.edu
Subject: Re: tail recursion
In-Reply-To: Your message of Mon, 23 Apr 90 15:06:14 CDT .
<9004232006.AA03672@sp21.csrd.uiuc.edu.>
Reply-To: markf@zurich.ai.mit.edu
Date: Mon, 23 Apr 90 16:47:44 EDT
From: markf@zurich.ai.mit.edu
>> ... Many implementation styles trade space for speed,
>> parallel implementations among them; your definition of proper
>> tail-recursion appears to disallow this.
I don't think that anyone is under the illusion that the requirement
for proper tail recursion is anything other than a space saving
optimization and that it may in fact be a time pessimizer for certain
architectures. I think perhaps that Jinx was just trying to say that
we can formalize this to whatever degree we like. If you don't like
the requirement for proper tail recursion, fine - argue for its
removal - but I think that it is dubious to argue that we don't know
what the requirement means.
-Mark
∂23-Apr-90 1428 halstead@crl.dec.com Re: tail recursion
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Apr 90 14:27:55 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA12298; Mon, 23 Apr 90 17:17:39 EDT
Received: from crl.dec.com (crl.dec.com) by zurich.ai.mit.edu; Mon, 23 Apr 90 17:15:28 edt
Received: by crl.dec.com; id AA06067; Mon, 23 Apr 90 17:16:51 -0400
Message-Id: <9004232116.AA01420@crlrhh.crl.dec.com>
To: Luddy Harrison <harrison@sp21.csrd.uiuc.edu>
Cc: halstead@crl.dec.com, rrrs-authors@zurich.ai.mit.edu
Subject: Re: tail recursion
In-Reply-To: Your message of Mon, 23 Apr 90 15:06:14 -0500.
<9004232006.AA03672@sp21.csrd.uiuc.edu.>
Date: Mon, 23 Apr 90 17:16:42 EDT
From: halstead@crl.dec.com
> Consider my dataflow example again. It may be that in order to
> achieve speedup, such a machine uses a quantity of "resources" that is
> not O(kX) where X is the consumption of M0. ...
Actually, this suggests an interesting idea: I can see a bunch of
arguments for limiting the "resource consumption" of any legal Scheme
implementation to O(f(X)) where X is the consumption on M0, independent
of how long the program runs. This in itself would rule out any
implementation (such as the naive, non-tail-recursive one) that uses
space of O(Xt), where t is the running time of the program. But is
there any reason to rule out O(X log X) space consumption? O(X↑2)?
O(X↑3)? O(2↑X)?! If any of these are permissible, do any of them offer
any useful flexibility to the designer? -Bert
∂23-Apr-90 1451 gls@think.com tail recursion
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Apr 90 14:51:16 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA12697; Mon, 23 Apr 90 17:38:54 EDT
Received: from Think.COM (think.com) by zurich.ai.mit.edu; Mon, 23 Apr 90 17:36:57 edt
Received: from Fafnir.Think.COM by Think.COM; Mon, 23 Apr 90 17:38:20 -0400
Received: from verdi.think.com by fafnir.think.com; Mon, 23 Apr 90 17:34:03 EDT
Received: from joplin.think.com by verdi.think.com; Mon, 23 Apr 90 17:38:14 EDT
From: gls@think.com (Guy Steele)
Received: by joplin.think.com; Mon, 23 Apr 90 17:38:10 EDT
Date: Mon, 23 Apr 90 17:38:10 EDT
Message-Id: <9004232138.AA00651@joplin.think.com>
To: halstead@crl.dec.com
Cc: rrrs-authors@zurich.ai.mit.edu, halstead@crl.dec.com,
harrison@sp21.csrd.uiuc.edu
In-Reply-To: halstead@crl.dec.com's message of Mon, 23 Apr 90 16:57:12 EDT <9004232057.AA01293@crlrhh.crl.dec.com>
Subject: tail recursion
I have a different definition to propose. Suppose we enumerate
the kinds of things that are *not* tail-recursive: evaluation
of the predicate part of an IF and evaluation of the subexpressions
of a call, for example. Suppose also that we can agree what we mean
by the state of a program (including all observable data structures,
the remainder of the computation to be performed, etc.).
Then I define an implementation to be properly tail-recursive if,
for every program state P,
if continued execution eventually causes state P to recur,
and every non-tail-recursive evaluation begun since
the first occurrence of state P has completed
before the second occurrence of state P
then state P will recur indefinitely many times without
running out of resources
An interesting question is whether we can show the two proposed
definitions to be equivalent or otherwise related.
--Guy
∂23-Apr-90 1503 harrison@sp21.csrd.uiuc.edu tail recursion
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Apr 90 15:02:58 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA12906; Mon, 23 Apr 90 17:52:51 EDT
Received: from uicsrd.csrd.uiuc.edu ([128.174.162.2]) by zurich.ai.mit.edu; Mon, 23 Apr 90 17:50:41 edt
Received: from sp21.csrd.uiuc.edu by uicsrd.csrd.uiuc.edu with SMTP
(5.61+/IDA-1.2.8) id AA05233; Mon, 23 Apr 90 16:50:54 -0500
Received: by sp21.csrd.uiuc.edu. (4.0/SMI-4.0)
id AA03740; Mon, 23 Apr 90 16:50:51 CDT
Date: Mon, 23 Apr 90 16:50:51 CDT
From: harrison@sp21.csrd.uiuc.edu (Luddy Harrison)
Message-Id: <9004232150.AA03740@sp21.csrd.uiuc.edu.>
To: gls@think.com, rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Guy Steele's message of Mon, 23 Apr 90 17:38:10 EDT <9004232138.AA00651@joplin.think.com>
Subject: tail recursion
>> for every program state P,
>> if continued execution eventually causes state P to recur,
>> and every non-tail-recursive evaluation begun since
>> the first occurrence of state P has completed
>> before the second occurrence of state P
>> then state P will recur indefinitely many times without
>> running out of resources
This is a wonderful definition. It appears, however, to have a hole
through which a tricky implementation would be entitled to jump. It
would permit me to be very consumptive of resources, could I
demonstrate that the repitition of states was impossible for an input
program.
-Luddy
∂23-Apr-90 1519 gls@think.com tail recursion
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Apr 90 15:19:30 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA13179; Mon, 23 Apr 90 18:08:10 EDT
Received: from Think.COM (think.com) by zurich.ai.mit.edu; Mon, 23 Apr 90 18:06:16 edt
Received: from Fafnir.Think.COM by Think.COM; Mon, 23 Apr 90 18:07:34 -0400
Received: from verdi.think.com by fafnir.think.com; Mon, 23 Apr 90 18:03:17 EDT
Received: from joplin.think.com by verdi.think.com; Mon, 23 Apr 90 18:07:27 EDT
From: gls@think.com (Guy Steele)
Received: by joplin.think.com; Mon, 23 Apr 90 18:07:26 EDT
Date: Mon, 23 Apr 90 18:07:26 EDT
Message-Id: <9004232207.AA00675@joplin.think.com>
To: harrison@sp21.csrd.uiuc.edu
Cc: gls@think.com, rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Luddy Harrison's message of Mon, 23 Apr 90 16:50:51 CDT <9004232150.AA03740@sp21.csrd.uiuc.edu.>
Subject: tail recursion
Date: Mon, 23 Apr 90 16:50:51 CDT
From: harrison@sp21.csrd.uiuc.edu (Luddy Harrison)
>> for every program state P,
>> if continued execution eventually causes state P to recur,
>> and every non-tail-recursive evaluation begun since
>> the first occurrence of state P has completed
>> before the second occurrence of state P
>> then state P will recur indefinitely many times without
>> running out of resources
This is a wonderful definition. It appears, however, to have a hole
through which a tricky implementation would be entitled to jump. It
would permit me to be very consumptive of resources, could I
demonstrate that the repitition of states was impossible for an input
program.
-Luddy
Yeah, but I suspect that the lurking possibility of having to handle the
halting problem in the general case will tend to keep implementors honest.
It will simply be easier to be reasonable than to cheat.
--Guy
∂23-Apr-90 1521 halstead@crl.dec.com Re: tail recursion
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Apr 90 15:21:39 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA13330; Mon, 23 Apr 90 18:14:02 EDT
Received: from crl.dec.com (crl.dec.com) by zurich.ai.mit.edu; Mon, 23 Apr 90 18:12:09 edt
Received: by crl.dec.com; id AA06253; Mon, 23 Apr 90 18:13:33 -0400
Message-Id: <9004232213.AA01831@crlrhh.crl.dec.com>
To: markf@zurich.ai.mit.edu
Cc: halstead@crl.dec.com, rrrs-authors@zurich.ai.mit.edu
Subject: Re: tail recursion
In-Reply-To: Your message of Mon, 23 Apr 90 16:47:44 -0400.
<9004232047.AA21460@zurich.ai.mit.edu>
Date: Mon, 23 Apr 90 18:13:24 EDT
From: halstead@crl.dec.com
> If you don't like
> the requirement for proper tail recursion, fine - argue for its
> removal - but I think that it is dubious to argue that we don't know
> what the requirement means.
Well, I'm not sure it's as dubious as all that. I think there are
implementation strategies that we would all agree are tail recursive, and
others that we would all agree aren't, but I bet there are still others
that would start violent arguments on this mailing list. Luddy's problem
is quite literally that he would like to experiment with new and quite
unconventional implementation strategies and he would like a rigorous
statement of where that boundary lies (presumably accompanied by a
convincing rationale) so he knows whether it makes sense to classify a
particular implementation as tail-recursive or not (and why).
We shouldn't assume from the foregoing discussion that we don't have any
idea what proper tail recursion means, but I don't think the discussion
demonstrates that we have a solid, unambiguous test for it either. -Bert
∂23-Apr-90 1523 harris@hplwhh.hpl.hp.com Re: tail recursion
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Apr 90 15:23:00 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA13256; Mon, 23 Apr 90 18:11:11 EDT
Received: from hplms2.hpl.hp.com ([15.255.176.66]) by zurich.ai.mit.edu; Mon, 23 Apr 90 18:09:05 edt
Received: from hplwhh.hpl.hp.com by hplms2.hpl.hp.com with SMTP
(15.11.1.3/15.5+IOS 3.20) id AA22966; Mon, 23 Apr 90 15:10:30 pdt
Received: from localhost by hplwhh.hpl.hp.com with SMTP
(15.11/15.5+IOS 3.14) id AA03179; Mon, 23 Apr 90 15:10:26 pdt
Message-Id: <9004232210.AA03179@hplwhh.hpl.hp.com>
To: rrrs-authors@zurich.ai.mit.edu
Subject: Re: tail recursion
In-Reply-To: Your message of "Mon, 23 Apr 90 16:50:51 CDT."
<9004232150.AA03740@sp21.csrd.uiuc.edu.>
Date: Mon, 23 Apr 90 15:10:24 PDT
From: Warren Harris <harris@hplwhh.hpl.hp.com>
There's a lot of talk about how tail-recursion affects resource utilization.
What about how it affects the programming environment? Certainly whether an
implementation performs tail-recursion elimination or not is visible in the
debugging process (e.g. in a backtrace). It's presence may make debugging more
difficult because intermediate stack frames may be eliminated. I think this
aspect is just as important as whether the machine runs out of stack space or
not. They're both properties of the implementation.
Warren
∂23-Apr-90 1547 gls@think.com tail recursion
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Apr 90 15:47:10 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA13694; Mon, 23 Apr 90 18:37:11 EDT
Received: from Think.COM (think.com) by zurich.ai.mit.edu; Mon, 23 Apr 90 18:35:19 edt
Received: from Fafnir.Think.COM by Think.COM; Mon, 23 Apr 90 18:36:39 -0400
Received: from verdi.think.com by fafnir.think.com; Mon, 23 Apr 90 18:32:23 EDT
Received: from joplin.think.com by verdi.think.com; Mon, 23 Apr 90 18:36:33 EDT
From: gls@think.com (Guy Steele)
Received: by joplin.think.com; Mon, 23 Apr 90 18:36:30 EDT
Date: Mon, 23 Apr 90 18:36:30 EDT
Message-Id: <9004232236.AA00680@joplin.think.com>
To: harris@hplwhh.hpl.hp.com
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Warren Harris's message of Mon, 23 Apr 90 15:10:24 PDT <9004232210.AA03179@hplwhh.hpl.hp.com>
Subject: tail recursion
Date: Mon, 23 Apr 90 15:10:24 PDT
From: Warren Harris <harris@hplwhh.hpl.hp.com>
There's a lot of talk about how tail-recursion affects resource utilization.
What about how it affects the programming environment? Certainly whether an
implementation performs tail-recursion elimination or not is visible in the
debugging process (e.g. in a backtrace). It's presence may make debugging more
difficult because intermediate stack frames may be eliminated. I think this
aspect is just as important as whether the machine runs out of stack space or
not. They're both properties of the implementation.
Warren
Seeing tail-recursive items on the stack is like seeing goto's
on the stack.
Sometimes a goto-trace can be pretty useful.
Time was when certain beloved computers kept a branch trace in
hardware (a ring buffer of the last PC or the last 16 or so PC's
from which you branched).
Seeing tail-recursive items on the stack is like seeing apply's
on the stack.
∂23-Apr-90 1606 halstead@crl.dec.com Re: tail recursion
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Apr 90 16:05:56 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA11928; Mon, 23 Apr 90 16:58:28 EDT
Received: from crl.dec.com (crl.dec.com) by zurich.ai.mit.edu; Mon, 23 Apr 90 16:56:35 edt
Received: by crl.dec.com; id AA05951; Mon, 23 Apr 90 16:57:21 -0400
Message-Id: <9004232057.AA01293@crlrhh.crl.dec.com>
To: rrrs-authors@zurich.ai.mit.edu
Cc: halstead@crl.dec.com, harrison@sp21.csrd.uiuc.edu
Subject: Re: tail recursion
In-Reply-To: Your message of Mon, 23 Apr 90 15:11:49 -0400.
<9004231911.AA20446@zurich.ai.mit.edu>
Date: Mon, 23 Apr 90 16:57:12 EDT
From: halstead@crl.dec.com
So far I think Jinx has the best handle on a reasonable definition of
the tail-recursion requirement in Scheme (whether or not we consider the
requirement to be a matter of "semantics"). Every physical machine
has finite resources (whether or not it is easy to view any of those
resources as "memory" in any traditional sense). So the way I would
apply Jinx's criterion would be to say that a Scheme implementation M
on some machine is properly tail-recursive if it can run every program
that runs successfully on the reference implementation M0 when M0 is
constrained to have only some (nontrivial?) quantity Q0 of memory.
Even a data-flow machine will run out of some resource (e.g., token
storage) if tries to keep too much data around, so I think this definition
applies just fine to data-flow machines.
One may argue whether this definition is a matter of "semantics," but I'd
certainly defend the definition as meaningful and relevant. On the other
hand, I'd hate to be the poor schmuck who's stuck with the job of proving
that some moderately complex, real-world implementation really satisfies
this criterion.
To the people who don't like this definition: what is there in it that
is either fuzzy or contrary to the intuitive or desirable specification
of Scheme's policy on tail calls? In what ways is the definition too
restrictive, or not restrictive enough?
To the people who do like it: I'm curious whether this definition
could ever be used as anything more than a debating device. Has
anybody tried to demonstrate the correctness of an implementation's
handling of tail calls using the level of rigor suggested by this
definition? -Bert
∂23-Apr-90 2120 gyro@ukulele.reasoning.com tail recursion
Received: from life.ai.mit.edu ([128.52.32.80]) by SAIL.Stanford.EDU with TCP; 23 Apr 90 21:20:32 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA18685; Tue, 24 Apr 90 00:15:07 EDT
Received: from drums.reasoning.com (reasoning.com) by zurich.ai.mit.edu; Tue, 24 Apr 90 00:12:32 edt
Received: from ukulele.reasoning.com by drums.reasoning.com with SMTP (5.61/25-eef)
id AA00274; Mon, 23 Apr 90 21:14:00 -0700
for jinx@zurich.ai.mit.edu
Received: by ukulele.reasoning.com. (4.0/SMI-4.0)
id AA08029; Mon, 23 Apr 90 21:14:01 PDT
Date: Mon, 23 Apr 90 21:14:01 PDT
From: gyro@ukulele.reasoning.com (Scott Layson Burson)
Message-Id: <9004240414.AA08029@ukulele.reasoning.com.>
To: jinx@zurich.ai.mit.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Guillermo J. Rozas's message of Sat, 21 Apr 90 10:22:56 edt <9004211422.AA29626@zurich.ai.mit.edu>
Subject: tail recursion
Date: Sat, 21 Apr 90 10:22:56 edt
From: jinx@zurich.ai.mit.edu (Guillermo J. Rozas)
Reply-To: jinx@zurich.ai.mit.edu
No, of course not. It's not a semantic property; it's an
implementation property.
I don't agree with you. You can have semantics at different levels,
depending only on how much magnification you want out of the semantics
microscope. It should not be hard to write a semantics with explicit
memory management where both of these properties are explicit. Of
course, the semantics would be (in most ways) much less informative
than the usual semantics that ignores such aspects.
The way that I like to define proper tail recursion is as follows:
[... deleted ...]
Just to be clear about where I stand:
I think the definition you present is very interesting and seems likely to
work, for all I can see now. I have no problem with -- in fact, I am strongly
in favor of -- including in the specification of Scheme the requirement that a
correct implementation be properly tail-recursive, and also including the best
definition we collectively can think of of what that means, which may very well
turn out to be the one you offer.
But I don't think that this is a *semantic* property, for the very simple
reason that it doesn't affect the *value* computed by any program under any
circumstances; it only affects whether a given program can be run on a given
implementation.
I guess this is a semantic argument. :-)
-- Scott
∂23-Apr-90 2218 gyro@ukulele.reasoning.com tail recursion and debugging
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Apr 90 22:18:41 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA19148; Tue, 24 Apr 90 01:05:46 EDT
Received: from drums.reasoning.com (reasoning.com) by zurich.ai.mit.edu; Tue, 24 Apr 90 01:03:50 edt
Received: from ukulele.reasoning.com by drums.reasoning.com with SMTP (5.61/25-eef)
id AA00300; Mon, 23 Apr 90 22:05:21 -0700
for rrrs-authors@zurich.ai.mit.edu
Received: by ukulele.reasoning.com. (4.0/SMI-4.0)
id AA08049; Mon, 23 Apr 90 22:05:22 PDT
Date: Mon, 23 Apr 90 22:05:22 PDT
From: gyro@ukulele.reasoning.com (Scott Layson Burson)
Message-Id: <9004240505.AA08049@ukulele.reasoning.com.>
To: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Warren Harris's message of Mon, 23 Apr 90 15:10:24 PDT <9004232210.AA03179@hplwhh.hpl.hp.com>
Subject: tail recursion and debugging
Date: Mon, 23 Apr 90 15:10:24 PDT
From: Warren Harris <harris@hplwhh.hpl.hp.com>
There's a lot of talk about how tail-recursion affects resource utilization.
What about how it affects the programming environment? Certainly whether an
implementation performs tail-recursion elimination or not is visible in the
debugging process (e.g. in a backtrace). It's presence may make debugging more
difficult because intermediate stack frames may be eliminated. I think this
aspect is just as important as whether the machine runs out of stack space or
not. They're both properties of the implementation.
I have been using a tail-recursive Common Lisp recently (Coral Common Lisp on
the Macintosh), and have formed some opinions about the interaction of tail
recursion and debugging. Specifically, I do sometimes miss those stack frames.
On the other hand, I also sometimes find it extremely handy to take advantage
of tail recursion.
Coral's implementation provides a global switch that one can use to turn off
the compiler's generation of tail-recursive code. This is an awfully blunt
instrument. Here is what I have proposed to them as an alternative arrangement
that I believe would satisfy me entirely:
1) Most calls would *not* be tail-recursive, except:
2) I could declare groups of functions such that calls from any one to any
other function in the group would be tail-recursive;
3) A top-level function and any functions declared inside it (i.e. with LABELS
or FLET) would automatically constitute such a group;
4) (optional) A declaration exists for overriding (3);
5) TAIL-FUNCALL is provided to override the default in specific cases.
Several CL compilers I know of implement (3) but not, to my knowledge, (2); but
I consider (2) to be a very important property (it makes possible a most
natural and convenient implementation of finite-state automata, for instance).
I believe, based on my experience to date, that this arrangement would let me
do everything I want to do with tail-recursion while still leaving those handy
stack frames around in the cases where it's not important to me that it remove
them.
I don't offhand see any difficulting in adapting this to Scheme; does anyone
else? -- Though I concede in advance the distastefulness of having something
like TAIL-FUNCALL (or perhaps just "TAIL-CALL" or maybe even "GOTO" (!!)) after
we've gone to such lengths to get rid of anything that looks like that. Even
so, I believe I would prefer this watering-down over uncompromising tail-
recursive purism.
On the other hand, maybe the use of the stack as the primary source of
information about the history of the computation is actually an unfortunate
historical accident. Maybe we should, as GLS hints, find other ways of
recording debugging information as it goes by. A FIFO buffer showing some
number of the most recent procedure invocations with their arguments would
often be much more useful than a stack backtrace, because after all, in a stack
backtrace there is no information whatever about values computed by frames that
have been returned from.
Well, I think this message will be controversial enough to kick off another
flurry of replies... here goes!
-- Scott
∂24-Apr-90 0000 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #353
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 24 Apr 90 00:00:23 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA19922; Tue, 24 Apr 90 02:58:13 EDT
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Tue, 24 Apr 90 02:56:06 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa29864;
24 Apr 90 2:49 EDT
Message-Id: <DIGEST.184.900424.020007.27@MC.LCS.MIT.EDU>
Date: 24 Apr 90 02:00:07 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #353
Scheme Digest #353 24 Apr 90 02:00:07 EDT
Today's Topics:
Looking for help with PC-PLUS
looking an ftp site for scheme
----------------------------------------------------------------------
Message-ID: <23apr9001@levels.sait.edu.au>
Date: 23 Apr 90 14:23:53 GMT
From: Boon Keong Teng <samsung!munnari.oz.au!sirius.ucs.adelaide.edu.au!levels!ET872532@think.com>
To: scheme@MC.lcs.mit.edu
Subject: Looking for help with PC-PLUS
To anyone who is familiar with the expert system "PC-PLUS".
The source code of Pc-Plus is written in SCHEME ,which is
very similar to LISP.
We are trying to call external functions and there are several
ways to do that :
(1) using "DOS-CALL" to call a function in DOS.
The external functions are written in BASIC.
Our problem is that we can't send parameters to the
external programs.
We can activate the external functions but then we have
to re-enter the values.
e.g. IF bla bla bla
THEN bla bla bla AND DOS-CALL "drive:filename.EXE"
" var1 var2 ... varN "
The stand-alone EXE file was made by using QBASIC.
After the program was run (in the PC-PLUS environment)
the screen got messed up pretty badly. The graphics and
text were all "smuched".
(2) another method is re-write all the programs in LISP .
The source code can be compiled using the EDWIN editor.
The problems with this mehtod are :
(a)converting the basic program to LISP
10 input cut_off_freq, q_factor
20 if cut_off_freq < 1000 then c1=1e-08
30 if cut_off_freq => 1000 and < 10000 then c1=1e-09
40 if cut_off_freq =>10000 and < 50000 then c1=1e-10
50 if cut_off_freq => 50000 then c1=1e-11
60 c2 = c1
70 c3 = 2 * c1
80 r1 = 1/(4 * pi * cut_off_freq * c1)
90 r2 = .......
100 r3 = .......
110 end
The output screen contains a circuit schematic as well as
the results of the program above.
The above program has TWO inputs and SIX variables.
c1 is dependent on the cut_off_freq. When I wrote this in
LISP it says the variables are not defined in the lexical
environment, PLEASE HELP!!!
(b) we can't get the LISP function to accept the values
send it either. We wrote a simple program to test
that.
I would very much to set up a personal contact with anyone who
can help us. THE EXPERT SYSTEM IS WRITTEN IN PCSCHEME 3.01.
PLEASE RESPONSE SOON . THANK YOU .
Boon Keong Teng. South Australian Institute of Technology.
------------------------------
Message-ID: <204@yaxkin.cs.utexas.edu>
Date: 23 Apr 90 23:03:38 GMT
From: Jaime Nino <samsung!cs.utexas.edu!jnino@think.com>
To: scheme@mc.lcs.mit.edu
Subject: looking an ftp site for scheme
I am looking for a site where I can ftp scheme. If you could, please comment
on the quality of the ftp version you know about.
Thanks.
J. Nino
------------------------------
End of Scheme Digest
********************
∂24-Apr-90 0545 jinx@zurich.ai.mit.edu tail recursion and debugging
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 24 Apr 90 05:44:34 PDT
Received: from zurich.ai.mit.edu (CHAMARTIN.AI.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA21898; Tue, 24 Apr 90 08:10:39 EDT
Received: from localhost by zurich.ai.mit.edu; Tue, 24 Apr 90 08:08:55 edt
Date: Tue, 24 Apr 90 08:08:55 edt
From: jinx@zurich.ai.mit.edu (Guillermo J. Rozas)
Message-Id: <9004241208.AA01678@zurich.ai.mit.edu>
To: gyro@ukulele.reasoning.com
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Scott Layson Burson's message of Mon, 23 Apr 90 22:05:22 PDT <9004240505.AA08049@ukulele.reasoning.com.>
Subject: tail recursion and debugging
Reply-To: jinx@zurich.ai.mit.edu
On the other hand, maybe the use of the stack as the primary
source of information about the history of the computation is
actually an unfortunate historical accident. Maybe we should, as
GLS hints, find other ways of recording debugging information as
it goes by. A FIFO buffer showing some number of the most recent
procedure invocations with their arguments would often be much
more useful than a stack backtrace, because after all, in a stack
backtrace there is no information whatever about values computed
by frames that have been returned from.
The MIT Scheme interpreter uses a history cache mechanism to record
reductions for some finite number of pending subproblems. It is
implemented as a set of circular buffers connected by a circular
spine, and the actual workings are pretty hairy, so it's only really
appropriate for an interpreter, but it is sometimes a real life-saver.
Because it's finite (and even worse, because of the invalidation
mechanism that we use), sometimes it does not contain the desired
information. However, users can, on demand, increase it's size
parameters before an execution, and often this allows the user to find
the wormhole through which her/his programs are jumping into
hyperspace.
∂24-Apr-90 1001 daniel@mojave.stanford.edu tail recursion
Received: from life.ai.mit.edu ([128.52.32.80]) by SAIL.Stanford.EDU with TCP; 24 Apr 90 10:01:42 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA03357; Tue, 24 Apr 90 12:24:52 EDT
Received: from mojave.Stanford.EDU (mojave.stanford.edu) by zurich.ai.mit.edu; Tue, 24 Apr 90 12:23:00 edt
Received: by mojave.Stanford.EDU (5.57/Ultrix2.4-C)
id AA07188; Tue, 24 Apr 90 09:20:30 PDT
Date: Tue, 24 Apr 90 09:20:30 PDT
From: daniel@mojave.stanford.edu (Daniel Weise)
Message-Id: <9004241620.AA07188@mojave.Stanford.EDU>
To: markf@zurich.ai.mit.edu
Cc: harrison@sp21.csrd.uiuc.edu, jinx@zurich.ai.mit.edu,
rrrs-authors@zurich.ai.mit.edu
In-Reply-To: markf@zurich.ai.mit.edu's message of Mon, 23 Apr 90 16:47:44 EDT <9004232047.AA21460@zurich.ai.mit.edu>
Subject: tail recursion
I don't think that anyone is under the illusion that the requirement
for proper tail recursion is anything other than a space saving
optimization
No. It is not just a space saving optimization, which is why it is
so important. I routinely write programs that run in CONSTANT SPACE
in a tail-recursive implementation, and which would rapidly die
in a non-tail recursive implementation. Tail recursive is a necessary
feature of Scheme, because my Scheme programs won't run in an
implementation without tail-recursion.
Would Scheme without garbage collection be Scheme? Would Scheme
without tail-recursion elimination be Scheme? These questions
are identical.
Daniel
∂24-Apr-90 1028 harrison@sp21.csrd.uiuc.edu tail recursion
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 24 Apr 90 10:28:11 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA03960; Tue, 24 Apr 90 12:48:51 EDT
Received: from uicsrd.csrd.uiuc.edu ([128.174.162.2]) by zurich.ai.mit.edu; Tue, 24 Apr 90 12:46:53 edt
Received: from sp21.csrd.uiuc.edu by uicsrd.csrd.uiuc.edu with SMTP
(5.61+/IDA-1.2.8) id AA03408; Tue, 24 Apr 90 11:47:58 -0500
Received: by sp21.csrd.uiuc.edu. (4.0/SMI-4.0)
id AA04593; Tue, 24 Apr 90 11:44:51 CDT
Date: Tue, 24 Apr 90 11:44:51 CDT
From: harrison@sp21.csrd.uiuc.edu (Luddy Harrison)
Message-Id: <9004241644.AA04593@sp21.csrd.uiuc.edu.>
To: daniel@mojave.stanford.edu, rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Daniel Weise's message of Tue, 24 Apr 90 09:20:30 PDT <9004241620.AA07188@mojave.Stanford.EDU>
Subject: tail recursion
>> Would Scheme without garbage collection be Scheme? Would Scheme
>> without tail-recursion elimination be Scheme? These questions
>> are identical.
I am a bit perplexed that people are responding to my question about
the meaning of proper tail-recursion by defending the requirement that
Scheme implementations be properly tail-recursive. First, I am not an
author of the Scheme proposal, and therefore even if I wanted the
requirement lifted (I do not), it should make little difference. Bert
stated my interest exactly: I want a test that I can apply to
novel implementations that will tell me unambiguously whether they are
properly tail-recursive.
If I understand the responses so far, two characterizations of proper
tail-recursion have been forwarded. One presents an interpreter M0,
and declares that an implementation is properly tail-recursive if it
requires O(kX) storage, where X is the requirement of M0 on a program
and k is a function only of the implementation.
The second definition is a characterization not of tail-recursion per
se, but of infinite looping: it requires that if a state recurs along
a tail-recursive control-flow path, that the program must loop
infintely (that is, it must not exhaust the memory). The objective of
this definition is to "force" proper tail-recursion in the general
case by requiring it of this special case.
-Luddy
∂24-Apr-90 1306 jeff%aiai.edinburgh.ac.uk@nsfnet-relay.ac.uk Re: tail recursion
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 24 Apr 90 13:06:16 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA07190; Tue, 24 Apr 90 15:29:38 EDT
Received: from NSFnet-Relay.AC.UK (nsfnet-relay.ac.uk) by zurich.ai.mit.edu; Tue, 24 Apr 90 15:27:42 edt
Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK
via Janet with NIFTP id aa21680; 24 Apr 90 16:24 BST
Date: Tue, 24 Apr 90 16:10:40 BST
Message-Id: <15680.9004241510@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@nsfnet-relay.ac.uk>
Subject: Re: tail recursion
To: Guy Steele <gls@think.com>
In-Reply-To: Guy Steele's message of Mon, 23 Apr 90 17:38:10 EDT
Cc: rrrs-authors@zurich.ai.mit.edu, halstead@crl.dec.com,
harrison%sp21.csrd.uiuc.edu@nsfnet-relay.ac.uk
> Then I define an implementation to be properly tail-recursive if,
> for every program state P,
> if continued execution eventually causes state P to recur,
> and every non-tail-recursive evaluation begun since
> the first occurrence of state P has completed
> before the second occurrence of state P
> then state P will recur indefinitely many times without
> running out of resources
What about cases where some storage is allocated that isn't part of
the evaluation of the recursion itself? (Reversing a list with an
accumulating parameter, say.) What about loops that take input from
the user? That is, when states don't recur, the definition doesn't
impose any restrictions at all on how the calls involved are
implemented.
It also seems to require garbage collection.
∂24-Apr-90 1349 halstead@crl.dec.com Re: tail recursion
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 24 Apr 90 13:49:36 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA08286; Tue, 24 Apr 90 16:16:19 EDT
Received: from crl.dec.com (crl.dec.com) by zurich.ai.mit.edu; Tue, 24 Apr 90 16:14:24 edt
Received: by crl.dec.com; id AA10008; Tue, 24 Apr 90 16:15:50 -0400
Message-Id: <9004242015.AA09604@crlrhh.crl.dec.com>
To: rrrs-authors@zurich.ai.mit.edu
Subject: Re: tail recursion
Date: Tue, 24 Apr 90 16:15:38 EDT
From: halstead@crl.dec.com
So far I think Jinx has the best handle on a reasonable definition of
the tail-recursion requirement in Scheme (whether or not we consider the
requirement to be a matter of "semantics"). Every physical machine
has finite resources (whether or not it is easy to view any of those
resources as "memory" in any traditional sense). So the way I would
apply Jinx's criterion would be to say that a Scheme implementation M
on some machine is properly tail-recursive if it can run every program
that runs successfully on the reference implementation M0 when M0 is
constrained to have only some (nontrivial?) quantity Q0 of memory.
Even a data-flow machine will run out of some resource (e.g., token
storage) if tries to keep too much data around, so I think this definition
applies just fine to data-flow machines.
One may argue whether this definition is a matter of "semantics," but I'd
certainly defend the definition as meaningful and relevant. On the other
hand, I'd hate to be the poor schmuck who's stuck with the job of proving
that some moderately complex, real-world implementation really satisfies
this criterion.
To the people who don't like this definition: what is there in it that
is either fuzzy or contrary to the intuitive or desirable specification
of Scheme's policy on tail calls? In what ways is the definition too
restrictive, or not restrictive enough?
To the people who do like it: I'm curious whether this definition
could ever be used as anything more than a debating device. Has
anybody tried to demonstrate the correctness of an implementation's
handling of tail calls using the level of rigor suggested by this
definition? -Bert
∂24-Apr-90 1400 gls@think.com tail recursion
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 24 Apr 90 14:00:28 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA09065; Tue, 24 Apr 90 16:53:00 EDT
Received: from Think.COM (think.com) by zurich.ai.mit.edu; Tue, 24 Apr 90 16:50:04 edt
Received: from Fafnir.Think.COM by Think.COM; Tue, 24 Apr 90 16:51:03 -0400
Received: from verdi.think.com by fafnir.think.com; Tue, 24 Apr 90 16:46:44 EDT
Received: from joplin.think.com by verdi.think.com; Tue, 24 Apr 90 16:50:53 EDT
From: gls@think.com (Guy Steele)
Received: by joplin.think.com; Tue, 24 Apr 90 16:50:50 EDT
Date: Tue, 24 Apr 90 16:50:50 EDT
Message-Id: <9004242050.AA00729@joplin.think.com>
To: jeff%aiai.edinburgh.ac.uk@nsfnet-relay.ac.uk
Cc: gls@think.com, rrrs-authors@zurich.ai.mit.edu, halstead@crl.dec.com,
harrison%sp21.csrd.uiuc.edu@nsfnet-relay.ac.uk
In-Reply-To: Jeff Dalton's message of Tue, 24 Apr 90 16:10:40 BST <15680.9004241510@subnode.aiai.ed.ac.uk>
Subject: tail recursion
Date: Tue, 24 Apr 90 16:10:40 BST
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
> Then I define an implementation to be properly tail-recursive if,
> for every program state P,
> if continued execution eventually causes state P to recur,
> and every non-tail-recursive evaluation begun since
> the first occurrence of state P has completed
> before the second occurrence of state P
> then state P will recur indefinitely many times without
> running out of resources
What about cases where some storage is allocated that isn't part of
the evaluation of the recursion itself? (Reversing a list with an
accumulating parameter, say.) What about loops that take input from
the user? That is, when states don't recur, the definition doesn't
impose any restrictions at all on how the calls involved are
implemented.
That is correct. This property is quite intentional. I believe that
there is very little else one can say about tail-recursion without
dragging in the question of representations of the data structures.
I don't have a good way to compare unequal states for their relative
memory consumption. One might think, for example, that if two
states are the same except for one list of NIL's, then the state
with the longer list ought to consume more memory; but it just isn't
so. Consider various data-compression techniques such as CDR-coding;
do we wish to rule them out by imposing a monotonicity requirement
on storage consumption?
Without a way to compare unequal states, I can discuss tail-recursion
only in terms of equal states. I agree that it is strange to define
tail-recursion, a property we wish to exploit in writing certain
interesting programs, as if solely in terms of the behavior of
UNinteresting programs.
Please, can anyone either refute or improve upon my definition?
It also seems to require garbage collection.
Yes, it probably does. That is an interesting point, but maybe
that is essential. Tail-recursive programs simply aren't allowed
to build up increasing state, whether "on the stack" or "in the heap"
(and in the presence of call/cc, what's the difference, after all?).
--Guy
∂24-Apr-90 1420 @zurich.ai.mit.edu,@mc.lcs.mit.edu,@ZERMATT.lcs.mit.edu:ziggy@hx.lcs.mit.edu tail recursion *is* semantic
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 24 Apr 90 14:20:29 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA09452; Tue, 24 Apr 90 17:12:12 EDT
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Tue, 24 Apr 90 17:10:16 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa29772;
24 Apr 90 17:06 EDT
Received: from ZERMATT.LCS.MIT.EDU (CHAOS 17316) by MC.LCS.MIT.EDU; 24 Apr 90 17:05:54 EDT
Received: from HX.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via INTERNET with SMTP id 27182; 24 Apr 90 17:05:41 EDT
Received: by hx.LCS.MIT.EDU (5.51/4.7); Tue, 24 Apr 90 17:04:27 EDT
Date: Tue, 24 Apr 90 17:04:27 EDT
From: "Michael R. Blair" <ziggy@hx.lcs.mit.edu>
Message-Id: <9004242104.AA08573@hx.LCS.MIT.EDU>
To: rrrs-authors@zermatt.lcs.mit.edu
Subject: tail recursion *is* semantic
From: gyro@ukulele.reasoning.com (Scott Layson Burson)
Subject: tail recursion
>But I don't think that this is a *semantic* property, for the very simple
>reason that it doesn't affect the *value* computed by any program under any
>circumstances; it only affects whether a given program can be run on a given
>implementation.
Actually it is a semantic issue. If your denotational semantics models a store
(which it must since Scheme has mutable values) then there should be a concept
of signalling an out-of-memory error when you try to allocate a cell but there
is no free memory. Presumably this would be conditional on the amount of memory
that your model is modelling, which would be fixed for a given invocation of
your language implementation on a given machine. Although most denotational
sematics supress this level of detail, to be a fully defined sematics it must be
concrete on this point.
Thus, if there exists a sufficiently large integer for which the value of some
tail-recursive procedure denotes out-of-memory-error (or bottom, or however you
model the notion in your semantics) when made to loop that many times but which
does not denote that same error when made to loop a small number of iterations,
then I would say your implementation is in violation of the Scheme
specification. Of course, this must be a fair tail-recursive loop, i.e. one that
does not otherwise consume memory, like by destructively consing elements onto a
global queue.
Again in defense of tail-recursion (somewhere along the line the discussion
seemed to turn to whether or not it was desireable), if I am not assured tail
recursion then I cannot implement meta-circular evaluators in an elegant,
straightforward way. If you make me resort to TAGBODIES with GOTOs then you
gross me out about as much as Bombin' LISP. I find this no less offensive than
calling for multiple namespaces in Scheme... moby-ick! ;-)
~Ziggy
∂24-Apr-90 1431 @zurich.ai.mit.edu,@mc.lcs.mit.edu,@zermatt.lcs.mit.edu:ziggy@hx.lcs.mit.edu Tail call vs debugging
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 24 Apr 90 14:31:04 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA09657; Tue, 24 Apr 90 17:26:46 EDT
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Tue, 24 Apr 90 17:24:55 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa00597;
24 Apr 90 17:24 EDT
Received: from ZERMATT.LCS.MIT.EDU (CHAOS 17316) by MC.LCS.MIT.EDU; 24 Apr 90 17:23:51 EDT
Received: from HX.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via INTERNET with SMTP id 27206; 24 Apr 90 17:23:42 EDT
Received: by hx.LCS.MIT.EDU (5.51/4.7); Tue, 24 Apr 90 17:22:33 EDT
Date: Tue, 24 Apr 90 17:22:33 EDT
From: "Michael R. Blair" <ziggy@hx.lcs.mit.edu>
Message-Id: <9004242122.AA08715@hx.LCS.MIT.EDU>
To: rrrs-authors@zermatt.lcs.mit.edu
Subject: Tail call vs debugging
I think asking for non-tail-recursion to be the default in a Scheme
language for reasons based n maintaining debugging information is
off base. For production quality code, you presume your code to be
correct and you compile it accordingly, paying as little bookkeeping
overhead as required.
To say that you dont want Scheme to require tail-recursion is, to me,
saying that you always want it to pay bookkeeping overhead even if
you are not in debugging mode (you, not your implementation). This
is unreasonable considering you can easily force a tail-recursive
call to be non-tail-recursive by wrapping it in a trivial LET (or if
your compiler optimizes this, by placing a DISPLAY/FORMAT/PRINTF
statement after it).
Would you also argue that every procedure defined should implicitly
be wrapped in a TRACE since this information too is useful for
debugging?
To me, your concern for tracing information is an important one
which should be supported by a language. I just don't think it
should be the default, to the exclusion of tail-recursion. If
you're debugging then debug, but if not don't take the performance
hit.
~ziggy
∂24-Apr-90 1841 RPG@sail.stanford.edu re: tail recursion
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 24 Apr 90 18:41:06 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA12779; Tue, 24 Apr 90 21:34:53 EDT
Received: from SAIL.Stanford.EDU (sail.stanford.edu) by zurich.ai.mit.edu; Tue, 24 Apr 90 21:32:40 edt
Message-Id: <vNvCH@SAIL.Stanford.EDU>
Date: 24 Apr 90 1832 PDT
From: Dick Gabriel <RPG@sail.stanford.edu>
Subject: re: tail recursion
To: rrrs-authors@zurich.ai.mit.edu
[In reply to message from gls@think.com sent Tue, 24 Apr 90 16:50:50 EDT.]
I guess I'm one of the rare people who wants to remove a requirement for
tail call removal. I also favor removing a requirement on a garbage
collector.
I favor including some remarks in the form of advice to implementors that
states that people who use Scheme will write programs that depend on
certain resource usage contraints, where tail call removal and garbage
collection are discussed, and that it is expected that such programs will
work a particular way. The phrasing in this section should be quite
strong, possibly even defining levels of implementation conformance, but
it should stop short of a hard implementation requirement.
But I want it to be allowed to call an implementation a `Scheme' even if I
am able only to run programs with certain restrictions.
Let me repeat my reason: I feel it is vitally important to get Scheme into
the mainstream, and it is better to place as few limitations on that
process as possible, at least for now. Tail call removal is possibly a
large barrier to certain compiler groups who would otherwise support
Scheme completely. At least at present.
Maybe the people on this list would not want to use that Scheme, but do
those people insist on the right to prevent people from calling that
implementation Scheme? And is that principle worth giving up inroads to
the mainstream?
-rpg-
∂24-Apr-90 1927 bartlett@wrl.dec.com Re: tail recursion
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 24 Apr 90 19:27:15 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA13170; Tue, 24 Apr 90 22:23:39 EDT
Received: from decpa.pa.dec.com ([16.1.240.23]) by zurich.ai.mit.edu; Tue, 24 Apr 90 22:21:28 edt
Received: by decpa.pa.dec.com; id AA24804; Tue, 24 Apr 90 19:22:44 -0700
Received: by jove.pa.dec.com; id AA19407; Tue, 24 Apr 90 19:22:40 -0700
Message-Id: <9004250222.AA19407@jove.pa.dec.com>
To: rrrs-authors@zurich.ai.mit.edu
Cc: bartlett@wrl.dec.com
Subject: Re: tail recursion
Date: Tue, 24 Apr 90 19:22:39 PDT
From: bartlett@wrl.dec.com
[In reply to RPG@sail.stanford.edu sent 24 Apr 90 1832 PDT]
Based on my experience implementing Scheme, I support rpg's proposal
that tail call removal be considered optional and implementers be given
strong advice on what might be expected from the system.
The Scheme-to-C system done at WRL, Scheme->C, grew out of a project
investigating the problems in implementing a LISP system on the WRL
built Titan. All compilers on the Titan are required to compile to an
intermediate language. This language is then optimized and compiled
into machine code for a specific hardware implementation.
Programs in the intermediate language are divided into procedures.
Within a procedure, one can transfer control by goto's, but the only
way to transfer control between procedures is via a call. The
intermediate language hides such things as general purpose registers
and the mechanics of procedure call and return. As is the case with
the MIPS intermediate language system, the Titan does not support tail call.
In order to fit Scheme into this environment, the rules were broken.
While many tail calls are converted into goto's, those that had to
cross procedure boundaries in the intermediate language are implemented
as conventional calls.
To date, this approach has worked. The users of this system seem to
feel that the advantages of an easily ported system with a compiler
that emits code that is compatible with other languages on the system
outweigh the fact that it doesn't do every tail call correctly.
jfb
∂24-Apr-90 1943 gyro@ukulele.reasoning.com tail recursion
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 24 Apr 90 19:43:10 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA13279; Tue, 24 Apr 90 22:35:52 EDT
Received: from drums.reasoning.com (reasoning.com) by zurich.ai.mit.edu; Tue, 24 Apr 90 22:33:58 edt
Received: from ukulele.reasoning.com by drums.reasoning.com with SMTP (5.61/25-eef)
id AA02554; Tue, 24 Apr 90 19:35:20 -0700
for rrrs-authors@zurich.ai.mit.edu
Received: by ukulele.reasoning.com. (4.0/SMI-4.0)
id AA20686; Tue, 24 Apr 90 19:35:21 PDT
Date: Tue, 24 Apr 90 19:35:21 PDT
From: gyro@ukulele.reasoning.com (Scott Layson Burson)
Message-Id: <9004250235.AA20686@ukulele.reasoning.com.>
To: RPG@sail.stanford.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Dick Gabriel's message of 24 Apr 90 1832 PDT <vNvCH@SAIL.Stanford.EDU>
Subject: tail recursion
Date: 24 Apr 90 1832 PDT
From: Dick Gabriel <RPG@sail.stanford.edu>
I guess I'm one of the rare people who wants to remove a requirement for
tail call removal. I also favor removing a requirement on a garbage
collector.
[...]
Let me repeat my reason: I feel it is vitally important to get Scheme into
the mainstream, and it is better to place as few limitations on that
process as possible, at least for now. Tail call removal is possibly a
large barrier to certain compiler groups who would otherwise support
Scheme completely. At least at present.
I don't understand this at all. What use is it to anyone -- us, or anyone else
-- if these mainstream compiler groups implement Schemes that work only on toy
problems?
Maybe the people on this list would not want to use that Scheme, but do
those people insist on the right to prevent people from calling that
implementation Scheme? And is that principle worth giving up inroads to
the mainstream?
Do we really do ourselves any favors by telling people, "If you implement this
spec, it will be Scheme", and having them go away and in good faith attempt to
meet the spec, only to show it to us and be told it's useless? That doesn't
sound like a way to make friends in the mainstream community. Far better that
we should drive home to them, as soon as possible (because it's easier for them
to change their designs now than later!), that we absolutely must have tail
call optimization and garbage collection.
I applaud you, Dick, for spearheading the effort to make this point to the
mainstream compiler people. I don't see that we have anything whatever to gain
by backing off on that project! In fact, if you will send me names and
addresses of people to write to, I will be happy to add my voice to yours. I
don't know if that will do any good; I'm not so public a figure even in the
Lisp community as you are; but I'm happy to try, and I'd much rather do that
than send exactly the wrong message by weakening the Scheme spec. I hope
others will volunteer too (GLS? are you listening?).
-- Scott
∂24-Apr-90 2003 harrison@sp21.csrd.uiuc.edu some implementations that are P.T.R.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 24 Apr 90 20:03:50 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA13649; Tue, 24 Apr 90 22:57:01 EDT
Received: from uicsrd.csrd.uiuc.edu ([128.174.162.2]) by zurich.ai.mit.edu; Tue, 24 Apr 90 22:54:37 edt
Received: from sp21.csrd.uiuc.edu by uicsrd.csrd.uiuc.edu with SMTP
(5.61+/IDA-1.2.8) id AA22776; Tue, 24 Apr 90 21:55:52 -0500
Received: by sp21.csrd.uiuc.edu. (4.0/SMI-4.0)
id AA05011; Tue, 24 Apr 90 21:55:49 CDT
Date: Tue, 24 Apr 90 21:55:49 CDT
From: harrison@sp21.csrd.uiuc.edu (Luddy Harrison)
Message-Id: <9004250255.AA05011@sp21.csrd.uiuc.edu.>
To: rrrs-authors@zurich.ai.mit.edu
Subject: some implementations that are P.T.R.
Are the following statements true of the M0 test? I am assuming that
the test is administered by someone who may observe the impelmentation
by running programs, but who may not examine the code of the
implementation.
A) Let k be V↑2, where V is the number of virtual addresses in my
machine. The M0 test states that every program will execute under
my implementation if it is given O(kX) bytes of storage. The
requirement is satisfied trivially: it is impossible.
B) My machine comes down once a month, rain or shine, for maintenance.
Let k be the number of clock periods in a month.
My implementation allocates and initializes a constant amount of
storage in the performance of every procedure call. It therefore
passes the M0 test.
C) My implementation keeps a count, in bignum form, of the number of
times that call/cc is invoked. (It runs on a machine that, unlike B
above, never goes down.) There is no apparent bound on the size of
this count. My implementation fails the M0 test even though its
handling of tail-recursion is unassailable.
D) My implementation uses a new representation for cons cells. I
prove in a lengthy JACM article that practically always, it cuts the
space requirement of Scheme programs by a factor of 200. However,
with probability smaller than that a chunk of the moon will
descend from space and destroy my workstation, the strategy produces a
quadrtic increase in the amount of storage required by a program. My
implementation fails the M0 test, and in despair I turn to work on
Fortran compilers.
∂24-Apr-90 2009 dyb@iuvax.cs.indiana.edu re: tail recursion
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 24 Apr 90 20:09:45 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA13749; Tue, 24 Apr 90 23:03:32 EDT
Received: from iuvax.cs.indiana.edu (iuvax.cs.indiana.edu) by zurich.ai.mit.edu; Tue, 24 Apr 90 23:01:30 edt
Message-Id: <9004250301.AA11885@zurich.ai.mit.edu>
Received: by iuvax.cs.indiana.edu
Date: Tue, 24 Apr 90 22:02:47 -0500
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
To: RPG@sail.stanford.edu
Subject: re: tail recursion
Cc: rrrs-authors@zurich.ai.mit.edu
> But I want it to be allowed to call an implementation a `Scheme' even if I
> am able only to run programs with certain restrictions.
I see nothing wrong with requiring implementors who don't handle tail
recursion or storage management adequately (however we end up defining
"adequately") to admit up front that their implementation is somewhat
deficient. They can still call the language they implement "Scheme",
but they can claim only partial conformance to the standard. If they
want to be fully conformant, they'll have to make the appropriate mods
to their common back end, if necessary.
If users are happy with a somewhat deficient version of Scheme, that's
okay with me, as long as it's made clear to them that they might be
missing something, i.e., that they are "able only to run programs with
certain restrictions."
We're much more likely to effect improvements in compiler technology
with a strong and coherent statement than we are by offering a
compromise right off the bat. I think it's naive to think that we can
start with a soft requirement now and hope to harden it later. I
understand that you don't believe we're in a position to effect any
such improvements, and maybe you're right, but I think we must include
proper treatment of tail recursion as a requirement now or give it up
forever. And I believe it's too important to Scheme to give it up.
Kent
∂24-Apr-90 2016 @zurich.ai.mit.edu,@mc.lcs.mit.edu,@zermatt.lcs.mit.edu:ziggy@hx.lcs.mit.edu Re: tail recursion (LONG)
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 24 Apr 90 20:15:55 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA13813; Tue, 24 Apr 90 23:09:50 EDT
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Tue, 24 Apr 90 23:07:54 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa13877;
24 Apr 90 23:08 EDT
Received: from ZERMATT.LCS.MIT.EDU (CHAOS 17316) by MC.LCS.MIT.EDU; 24 Apr 90 23:08:23 EDT
Received: from HX.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via INTERNET with SMTP id 27357; 24 Apr 90 23:08:11 EDT
Received: by hx.LCS.MIT.EDU (5.51/4.7); Tue, 24 Apr 90 23:07:01 EDT
Date: Tue, 24 Apr 90 23:07:01 EDT
From: "Michael R. Blair" <ziggy@hx.lcs.mit.edu>
Message-Id: <9004250307.AA10557@hx.LCS.MIT.EDU>
To: rrrs-authors@zermatt.lcs.mit.edu
Subject: Re: tail recursion (LONG)
My feeling is that a language which does not support both tail-recursion and
call/cc is not a true Scheme. I have used two such non-Scheme languages for
several years and have not found them to be unuseable, but I constantly had to
remind myself that they are not full Scheme implementations.
One of them is Jonathan Rees' PseudoScheme. The other is TI's Almost Scheme.
Both are packages built on top of Common Lisp. (In fact, TI's Almost Scheme
borrows code from Rees' PseudoScheme). Both are very nice to use, BUT...
I think it is important for people using such variant implementations to be very
aware of the limitations of their implementations. I therefore resist allowing
such implementations to claim to be full ``Scheme'' implementations. I would
not object to a section in the standard/report which says that such
implementations may exist but must not purport to be a full Scheme implementa-
tion. They should instead include some sort of qualifier in their name... like
Pseudo, Quasi, or Almost. To do otherwise is to bring up the issue of portabil-
ity of *real* Scheme code with respect to these deficient implementations.
Maybe a less judgemental phrasing like ``this is a Scheme Level 0 implementation
in that it does not have tail-recursion or call/cc''; ``this is a Scheme Level 1
implementation in that it does not have tail-recursion'' etc. would be less
offensive than PSeudo and the like.
Specific to the issue of tail-recursion: if I create a large software system as
a meta-circular interpreter then it had better not crash simply because the
deficient Scheme I am running it on does not have tail recursion. I do not want
users of my program to think that I am an idiot for writing a system that will
crash after being run for only a few hours; I want them instead to understand
that their code crashes because of a limitation of their langauage
implementation. Forcing the Scheme vendor who sold them (or gave them) their
Scheme to include a qualifier would protect my reputation and appease my ego.
I just don't want people flaming at me because my code won't load or run right
on their less-than-Scheme language. It shouldn't be my problem: it is theirs and
I don't want to hear them complain to me about it. I especially don't want them
to use my code expecting it to work if they have a weak Scheme. Otherwise, I
would have just written the trash in Common Lisp and have had done with it. To
make *me* provide a disclaimer like ``This code runs only on *full* Scheme
implementations: i.e., ones with tail-recursion and full call/cc'' is to rewrite
history by redefining the word ``Scheme'' in an Orwellian way. In my mind this
is analogous to saying: I have an ML which doesn't implement type inference, or
I have a FORTRAN that doesn't support IEE floating point numbers, or I have a
Haskell which isn't lazy, or I have a LISP that has no CONS.
Please stop trying to require Scheme to be Common Lisp compatible. Instead,
phrase your proposals in terms of ``Let's allow Level 0 implementations to be
deficient in the following ways...'' I get defensive when you try to desecrate
my religious icons.
I didn't intend to flame on like that. I won't push this point any further.
Maybe I'll just move to a Common Lisp mailing list and assault it with proposals
that they admit variants with only one namespace or that they mandate
tail-recursion.
ziggy
∂25-Apr-90 1054 mkatz@garlic.stanford.edu tail recursion
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 25 Apr 90 10:53:58 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA21922; Wed, 25 Apr 90 13:09:13 EDT
Received: from garlic.Stanford.EDU ([36.22.0.43]) by zurich.ai.mit.edu; Wed, 25 Apr 90 13:06:52 edt
Received: by garlic.Stanford.EDU (5.57/Ultrix3.0-C)
id AA02429; Wed, 25 Apr 90 08:44:20 PDT
Date: Wed, 25 Apr 90 08:44:20 PDT
From: mkatz@garlic.stanford.edu (Morris Katz)
Message-Id: <9004251544.AA02429@garlic.Stanford.EDU>
To: RPG@sail.stanford.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Dick Gabriel's message of 24 Apr 90 1832 PDT <vNvCH@SAIL.Stanford.EDU>
Subject: tail recursion
Maybe the people on this list would not want to use that Scheme, but do
those people insist on the right to prevent people from calling that
implementation Scheme? And is that principle worth giving up inroads to
the mainstream?
I believe that in fact it is important to prevent people who build substandard
implementations from calling them Scheme. The reality of the real world is
that a single widely distributed, substandard version of Scheme could give the
language a bad name throughout the non-research community for all time. I
would not want to see Scheme vilified by a group of uninformed people based on
a broken implementation. I can easily see people complaining, for example,
that scheme lacks flexible enough iteration constructs based on using an
implementation sans proper tail-recursion. This would completely miss the
point of Scheme, but would still serve to sully its name.
-------------------------------------------------------------------------------
Morry Katz
katz@cs.stanford.edu
-------------------------------------------------------------------------------
∂25-Apr-90 1114 @zurich.ai.mit.edu,@RELAY.CS.NET,@tektronix.tek.com:kend@mrloog.wr.tek.com
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 25 Apr 90 11:14:28 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA23047; Wed, 25 Apr 90 13:59:45 EDT
Received: from RELAY.CS.NET (relay.cs.net) by zurich.ai.mit.edu; Wed, 25 Apr 90 13:57:54 edt
Received: from tektronix.tek.com by RELAY.CS.NET id aa28670; 25 Apr 90 13:22 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
id AA28691; Wed, 25 Apr 90 10:26:59 PDT
Received: by wrgate.wr.tek.com (5.51/7.1)
id AA03635; Wed, 25 Apr 90 10:22:05 PDT
Received: by mrloog.WR.TEK.COM (1.2/7.1)
id AA27745; Wed, 25 Apr 90 10:22:02 pdt
Message-Id: <9004251722.AA27745@mrloog.WR.TEK.COM>
To: rrrs-authors@zurich.ai.mit.edu
Subject:
Date: 25 Apr 90 10:21:54 PDT (Wed)
From: kend%mrloog.wr.tek.com@relay.cs.net
RPG> Let me repeat my reason: I feel it is vitally important to get Scheme into
RPG> the mainstream, and it is better to place as few limitations on that
RPG> process as possible, at least for now. Tail call removal is possibly a
RPG> large barrier to certain compiler groups who would otherwise support
RPG> Scheme completely. At least at present.
JFB> As is the case with the MIPS intermediate language system, the Titan does
JFB> not support tail call.
This is precisely the problem. Changing Scheme because of implementors
not supporting tail calls properly is a first class example (sorry) of
the tail wagging the dog. Tail recursion optimization is a general win
[I have even seen it done in FORTRAN]. I think that it is very
important that compiler implementors be aware of more implementation
techniques than needed for Edison or PCC.
I use Scheme in small (i.e. embedded) systems with real memory. I depend
on tail call optimization. In order to get Scheme into mainstream *usage*,
efficient, high-quality implementations are needed. Bumming the
implementation to make it easy for compiler writers to remain provincial
will not do this.
[Joel, I have used Scheme->C for some X11 stuff. It is a great system.
I don't mind you calling it Scheme with some restrictions. But as a
Scheme user, I *depend* on tail calls].
-Ken Dickey
∂25-Apr-90 1449 harrison@sp21.csrd.uiuc.edu tail-recursion
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 25 Apr 90 14:49:36 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA27555; Wed, 25 Apr 90 17:38:34 EDT
Received: from uicsrd.csrd.uiuc.edu ([128.174.162.2]) by zurich.ai.mit.edu; Wed, 25 Apr 90 17:36:41 edt
Received: from sp21.csrd.uiuc.edu by uicsrd.csrd.uiuc.edu with SMTP
(5.61+/IDA-1.2.8) id AA23820; Wed, 25 Apr 90 16:37:48 -0500
Received: by sp21.csrd.uiuc.edu. (4.0/SMI-4.0)
id AA05952; Wed, 25 Apr 90 16:37:45 CDT
Date: Wed, 25 Apr 90 16:37:45 CDT
From: harrison@sp21.csrd.uiuc.edu (Luddy Harrison)
Message-Id: <9004252137.AA05952@sp21.csrd.uiuc.edu.>
To: rrrs-authors@zurich.ai.mit.edu
Subject: tail-recursion
If it should be decided to speak of tail-recursion in the standard,
allow me, as a consumer of the standard, to recommend Guy's
definition. First, it is quite easy to test: an example like Kent's
can be run, and the fact that it loops forever will be very convincing
evidence of proper tail-recursion. Moreover, Guy's definition gives a
infinitude of such examples.
Second, it seems quite a bit easier to prove of an implementation than
the M0 test. I must only be able to speak of identical states,
whatever they might be in my implementation, and then characterize the
evaluator when it encounters identical states along a chain of
tail-recursive calls.
Third, it is independent of issues other than proper tail-recursion.
The M0 test has the bad property that if I pass it, and then change my
representation of hashtables, I might fail it (for a reason that has
nothing to do with tail-recursion).
Kent's proposed characterization (p1 => ... => pn is no more
consumptive of storage than p1 => pn) has a similar effect, but is
slightly weaker than Guy's test, as it does not require infinite
looping the way Guy's test does.
-Luddy
∂25-Apr-90 1753 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #354
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 25 Apr 90 17:52:34 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA17834; Wed, 25 Apr 90 03:49:15 EDT
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Wed, 25 Apr 90 03:47:25 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa20231;
25 Apr 90 3:38 EDT
Message-Id: <DIGEST.184.900425.021652.32@MC.LCS.MIT.EDU>
Date: 25 Apr 90 02:16:52 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #354
Scheme Digest #354 25 Apr 90 02:16:52 EDT
Today's Topics:
looking an ftp site for scheme
----------------------------------------------------------------------
Message-ID: <23728@cs.yale.edu>
Date: 24 Apr 90 13:44:52 GMT
From: Duke Briscoe <cs.yale.edu!briscoe-duke@yale-zoo.arpa>
To: scheme@mc.lcs.mit.edu
Subject: Re: looking an ftp site for scheme
The T language includes an environment for Scheme, and from my
experience I judge it to be at least 99% conformant to the Scheme
standard, and there isn't any performance penalty for using T to run
Scheme since the Scheme environment just allows a different set of
names to be used for the underlying T functions. T also provides some
useful extensions to Scheme. T has an optimizing compiler, and best
of all it is available by anonymous ftp from wheaties.ai.mit.edu
(128.52.32.6) in the pub/t3.1 directory. That directory contains
binaries and sources for T3.1. Currently available versions are for
Dec3100(pmax), Sun4(sparc),Sun3, Vax/Unix, Encore, Hp workstation,
Apollo and Mac/Aux. The online version of the T manual is also there
as well as release notes for T3.0 and T3.1. For Sun and Vax there is
a C/Unix interface to T.
From masala.lcs.mit.edu (18.27.0.200) in the pub directory you can get
a T dialect extended for parallelism (uses the future construct)
called Mul-T; it runs on the Encore Multimax.
------------------------------
End of Scheme Digest
********************
∂26-Apr-90 1406 RPG@sail.stanford.edu re: tail-recursion
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 26 Apr 90 14:05:12 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA06715; Thu, 26 Apr 90 16:56:50 EDT
Received: from SAIL.Stanford.EDU (sail.stanford.edu) by zurich.ai.mit.edu; Thu, 26 Apr 90 16:54:53 edt
Message-Id: <18Ortm@SAIL.Stanford.EDU>
Date: 26 Apr 90 1355 PDT
From: Dick Gabriel <RPG@sail.stanford.edu>
Subject: re: tail-recursion
To: rrrs-authors@zurich.ai.mit.edu
[In reply to message from harrison@sp21.csrd.uiuc.edu sent Wed, 25 Apr 90 16:37:45 CDT.]
The creation of a standard language is done because there is a perceived
need to unify a community, and often to satisfy commercial needs. Once the
step is taken to start a standardization process, one needs to consider
the ramifications of operating in the real world.
One group I am trying to influence is a compiler backend group that is
doing a backend to support all languages at a very large computer company
that has never had a common backend before. This group, which is fairly
small, has monthly milestones laid out in front of from now until
mid-1992. They will support every language you can think of except
SmallTalk and PROLOG, and the machine architectures they will target are
challenging, to say the least.
Now, how do you propose that I persuade them to put in an optimization for
Scheme? How do I convince them that the compiler switches needed to turn
this off for debugging in other languages is worth their effort? Should I
count up the 10000 Scheme programmers for them, noting that nearly all of
them are in universities and are generally just playing around?
No, among other things, I try to convince them that Scheme would make an
excellent extension language, and that several groups at their company
have need for one (I also argue that it is a good optimization for other
languages). Now, when they come back and tell me that extension languages
are mostly for extending command languages and that lengthy iterations are
not common or never done, and that the extension language groups should
just add a simple iterative construct for that, how am I to argue against
it?
Couple this with the fact that Scheme is a standard language, which is a
drawing point for the various extension language groups, and with the fact
that the language definition does not let them call their implementation a
conforming implementation. Note that other languages have various levels
of conformance, so this is not such an outrageous thing.
I could persuade them more effectively if I could point to a larger
programmer community, which I could do if I could get some variety of
Scheme into the mainstream, which I could do if I could only get the
definers of the language to allow a mainstream implementation to be called
a Scheme.
If you wanted to keep your language to yourselves, you shouldn't have
opened up the gates of standardization, which has severe backpressure on
the R...RS language. (By the way, I argued against standarization of
Scheme.)
Someone conjectured that if we `cave in' on tail call removal, we will
never get these outsiders to adopt it, because, hey, they won their
argument. Well, I cannot think of gentle enough words to use to educate
this someone that the real world of negotiation is not like a trivial war
board game. Once agreements are made in such a way that you can establish
technical collegiality, additional compromises can be made which will
enable complete implementations.
Someone else said this:
``Please stop trying to require Scheme to be Common Lisp compatible.
Instead, phrase your proposals in terms of ``Let's allow Level 0
implementations to be deficient in the following ways...'' ''
Fortunately, this person was not referring to me, because my proposals had
always been of the form of allowing for deficient implementatations along
specified dimensions (I possibly am making the mistake of assuming that if
two sentences appear adjacently in the same paragraph, they are related).
(As I understand, almost all Scheme implementations are horribly deficient
anyway because they use intrusive GC techniques, and the ones that support
generation scavenging type techniques are slightly deficient because they
aren't incremental or real time. Also, most don't support the full range
of available compiler optimizations, and maybe only one does automatic
fine-grained parallelism detection, and maybe none of them have
floating-point computation competitive with FORTRAN.)
The first sentence of the quote, though, makes me wonder whom we think is
the enemy, and why we think there is one. I have been associated with the
Scheme community since 1976, when my friends Sussman and Steele started
writing their papers outlining Scheme. I have been associated with the
Common Lisp community since it started, and I helped start it. I feel no
oddness in programming in either one depending on what I am doing. I feel
no strangeness that I do my commercial work with CL and my research work
with an extended Scheme. I do not find myself ill and distorted because of
the two computers I have access to at home, one has CL and the other
Scheme. I have a lengthy list of critiques of CL, and an equally lengthy
one of Scheme.
The outside world feels that Scheme and Lisp are nearly the same language,
only one is a lot bigger than the other. The majority of the CL community
has great respect for the Scheme community. Do you not have that same
respect for them? The members of the CL community are returing from the
forest with the arrows of commercial battle in their backs; possibly we
should try to learn what happened to them so as to not make the same
mistakes?
One big mistake is to think that some other language is an enemy. We at
the CL companies once thought that there was a C versus Lisp battle. No
such thing ever happened. It was a matter of defining requirements for
Lisp being in the mainstream and meeting those requirements. Similarly,
there is no such thing as a Common Lisp versus Scheme battle. If someone
who operates in the Common Lisp world makes a suggestion, it is usually
for reasons other than wishing Scheme to become more Common-Lisp-like.
Besides, who mentioned CL in the first place? Not me.
Oh, by the way, I convinced that compiler backend group to put in tail
call removal. I did it by pointing out that the CL my company supplies to
them will need to use their backends in 1992, and that for my
implementation to work well, tail call removal needs to be supported by
the compiler. One down, 10 to go.
-rpg-
∂26-Apr-90 1419 jeff%aiai.edinburgh.ac.uk@nsfnet-relay.ac.uk Re: tail recursion
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 26 Apr 90 14:19:08 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA06853; Thu, 26 Apr 90 17:10:24 EDT
Received: from NSFnet-Relay.AC.UK (nsfnet-relay.ac.uk) by zurich.ai.mit.edu; Thu, 26 Apr 90 17:08:30 edt
Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK
via Janet with NIFTP id aa18681; 26 Apr 90 21:17 BST
Date: Thu, 26 Apr 90 21:24:37 BST
Message-Id: <29098.9004262024@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@nsfnet-relay.ac.uk>
Subject: Re: tail recursion
To: Guy Steele <gls@think.com>
In-Reply-To: Guy Steele's message of Tue, 24 Apr 90 16:50:50 EDT
Cc: rrrs-authors@zurich.ai.mit.edu
> > Then I define an implementation to be properly tail-recursive if,
> > for every program state P,
> > if continued execution eventually causes state P to recur,
> > and every non-tail-recursive evaluation begun since
> > the first occurrence of state P has completed
> > before the second occurrence of state P
> > then state P will recur indefinitely many times without
> > running out of resources
>
> What about cases where some storage is allocated that isn't part of
> the evaluation of the recursion itself? [...] That is, when states
> don't recur, the definition doesn't impose any restrictions at all
> on how the calls involved are implemented.
>
> That is correct. This property is quite intentional. I believe that
> there is very little else one can say about tail-recursion without
> dragging in the question of representations of the data structures.
Humm. It's no doubt an interesting property; it's just hard to see
that it's a definition of tail recursion.
∂26-Apr-90 1438 gls@think.com tail recursion
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 26 Apr 90 14:37:58 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA07006; Thu, 26 Apr 90 17:28:16 EDT
Received: from Think.COM (think.com) by zurich.ai.mit.edu; Thu, 26 Apr 90 17:26:21 edt
Received: from Fafnir.Think.COM by Think.COM; Thu, 26 Apr 90 17:27:42 -0400
Received: from verdi.think.com by fafnir.think.com; Thu, 26 Apr 90 17:23:22 EDT
Received: from joplin.think.com by verdi.think.com; Thu, 26 Apr 90 17:27:34 EDT
From: gls@think.com (Guy Steele)
Received: by joplin.think.com; Thu, 26 Apr 90 17:27:31 EDT
Date: Thu, 26 Apr 90 17:27:31 EDT
Message-Id: <9004262127.AA00927@joplin.think.com>
To: jeff%aiai.edinburgh.ac.uk@nsfnet-relay.ac.uk
Cc: gls@think.com, rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Jeff Dalton's message of Thu, 26 Apr 90 21:24:37 BST <29098.9004262024@subnode.aiai.ed.ac.uk>
Subject: tail recursion
Date: Thu, 26 Apr 90 21:24:37 BST
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@nsfnet-relay.ac.uk>
> > Then I define an implementation to be properly tail-recursive if,
> > for every program state P,
> > if continued execution eventually causes state P to recur,
> > and every non-tail-recursive evaluation begun since
> > the first occurrence of state P has completed
> > before the second occurrence of state P
> > then state P will recur indefinitely many times without
> > running out of resources
>
> What about cases where some storage is allocated that isn't part of
> the evaluation of the recursion itself? [...] That is, when states
> don't recur, the definition doesn't impose any restrictions at all
> on how the calls involved are implemented.
>
> That is correct. This property is quite intentional. I believe that
> there is very little else one can say about tail-recursion without
> dragging in the question of representations of the data structures.
Humm. It's no doubt an interesting property; it's just hard to see
that it's a definition of tail recursion.
It isn't; in fact, it relies on a pre-existing definition of what
it means for a situation to be tail-recursive. Rather, it is a
constraint on how an implementation will behave in such situations.
∂26-Apr-90 1452 jeff%aiai.edinburgh.ac.uk@nsfnet-relay.ac.uk re: tail recursion
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 26 Apr 90 14:52:29 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA07189; Thu, 26 Apr 90 17:41:32 EDT
Received: from NSFnet-Relay.AC.UK (nsfnet-relay.ac.uk) by zurich.ai.mit.edu; Thu, 26 Apr 90 17:39:38 edt
Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK
via Janet with NIFTP id aa18930; 26 Apr 90 21:27 BST
Date: Thu, 26 Apr 90 21:34:31 BST
Message-Id: <29122.9004262034@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@nsfnet-relay.ac.uk>
Subject: re: tail recursion
To: Dick Gabriel <RPG@sail.stanford.edu>, rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Dick Gabriel's message of 24 Apr 90 1832 PDT
> Let me repeat my reason: I feel it is vitally important to get Scheme into
> the mainstream, and it is better to place as few limitations on that
> process as possible, at least for now. Tail call removal is possibly a
> large barrier to certain compiler groups who would otherwise support
> Scheme completely. At least at present.
How serious is this problem? Right now, different languages don't
seem to _have_ to share back ends. On machines where languages would
normally work this way, what happens to those that don't fit? Can
they not be implemented at all?
I also have a question about how standards work. If someone doesn't
conform completely, they can list their deficiencies. But where/when
do they have to note them? Can they never say they're Scheme without
making some qualifications, or can they leave that kind of thing for
the documentation, or what?
In other words, if we the standard says Scheme has to be tail-recursive,
how much does this actually accomplish?
-- Jeff
∂27-Apr-90 0020 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #355
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 27 Apr 90 00:20:21 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA12618; Fri, 27 Apr 90 03:13:32 EDT
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Fri, 27 Apr 90 03:11:40 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa10335;
27 Apr 90 3:06 EDT
Message-Id: <DIGEST.184.900427.024803.44@MC.LCS.MIT.EDU>
Date: 27 Apr 90 02:48:02 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #355
Scheme Digest #355 27 Apr 90 02:48:02 EDT
Today's Topics:
Looking for help with PC-PLUS
----------------------------------------------------------------------
Message-ID: <7671@ubc-cs.UUCP>
Date: 27 Apr 90 01:43:05 GMT
From: Vincent Manis <ubc-cs!manis@beaver.cs.washington.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: Looking for help with PC-PLUS
I would strongly recommend sitting down with a textbook on Scheme
programming (Jerry Smith's `An Introduction to Scheme' [Prentice-Hall]
might be right for you). After having learned Scheme, you will have no
trouble translating your Basic code into Scheme procedures. That, rather
than using DOS-CALL, is the preferred way of doing things.
--
\ Vincent Manis <manis@cs.ubc.ca> "There is no law that vulgarity and
\ Department of Computer Science literary excellence cannot coexist."
/\ University of British Columbia -- A. Trevor Hodge
/ \ Vancouver, BC, Canada V6T 1W5 (604) 228-2394
------------------------------
End of Scheme Digest
********************
∂27-Apr-90 0645 harrison@sp21.csrd.uiuc.edu tail recursion
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 27 Apr 90 06:45:17 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA19708; Fri, 27 Apr 90 09:38:17 EDT
Received: from uicsrd.csrd.uiuc.edu ([128.174.162.2]) by zurich.ai.mit.edu; Fri, 27 Apr 90 09:36:03 edt
Received: from sp21.csrd.uiuc.edu by uicsrd.csrd.uiuc.edu with SMTP
(5.61+/IDA-1.2.8) id AA00198; Fri, 27 Apr 90 08:36:36 -0500
Received: by sp21.csrd.uiuc.edu. (4.0/SMI-4.0)
id AA07390; Fri, 27 Apr 90 08:36:34 CDT
Date: Fri, 27 Apr 90 08:36:34 CDT
From: harrison@sp21.csrd.uiuc.edu (Luddy Harrison)
Message-Id: <9004271336.AA07390@sp21.csrd.uiuc.edu.>
To: jeff@aiai.edinburgh.ac.uk, RPG@sail.stanford.edu,
rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Jeff Dalton's message of Thu, 26 Apr 90 21:34:31 BST <29122.9004262034@subnode.aiai.ed.ac.uk>
Subject: tail recursion
> One group I am trying to influence is a compiler backend group that is
> doing a backend to support all languages at a very large computer company
> that has never had a common backend before. This group, which is fairly
> small, has monthly milestones laid out in front of from now until
> mid-1992. They will support every language you can think of except
> SmallTalk and PROLOG, and the machine architectures they will target are
> challenging, to say the least.
> Let me repeat my reason: I feel it is vitally important to get Scheme into
> the mainstream, and it is better to place as few limitations on that
> process as possible, at least for now. Tail call removal is possibly a
> large barrier to certain compiler groups who would otherwise support
> Scheme completely. At least at present.
Dick, I don't understand this, on technical grounds. Think of all the
stuff that has to be supported in "the back end" to bring up a Scheme
implementation: garbage collection; heap-allocated activation records
(environments); call/cc (!); and so on. If we assume that CL is to be
supported as well, then add dynamic binding to the list. You are
describing language implementors that are ready to provide all of this
stuff, and on exotic architectures, but for whom the rewriting of
procedure calls into branches is a major obstacle. ??
-Luddy
∂27-Apr-90 0815 jinx@zurich.ai.mit.edu tail recursion
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 27 Apr 90 08:14:54 PDT
Received: from zurich.ai.mit.edu (CHAMARTIN.AI.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA20524; Fri, 27 Apr 90 11:06:49 EDT
Received: from localhost by zurich.ai.mit.edu; Fri, 27 Apr 90 11:05:06 edt
Date: Fri, 27 Apr 90 11:05:06 edt
From: jinx@zurich.ai.mit.edu (Guillermo J. Rozas)
Message-Id: <9004271505.AA18380@zurich.ai.mit.edu>
To: bartlett@wrl.dec.com
Cc: rrrs-authors@zurich.ai.mit.edu, bartlett@wrl.dec.com
In-Reply-To: bartlett@wrl.dec.com's message of Tue, 24 Apr 90 19:22:39 PDT <9004250222.AA19407@jove.pa.dec.com>
Subject: tail recursion
Reply-To: jinx@zurich.ai.mit.edu
In order to fit Scheme into this environment, the rules were broken.
While many tail calls are converted into goto's, those that had to
cross procedure boundaries in the intermediate language are implemented
as conventional calls.
To date, this approach has worked. The users of this system seem to
feel that the advantages of an easily ported system with a compiler
that emits code that is compatible with other languages on the system
outweigh the fact that it doesn't do every tail call correctly.
The question is whether the compromise was necessary. There are ways,
although perhaps expensive, to achieve both goals. You decided that
further investment into maintaining tail recursion was unnecessary,
and I may even agree with your decision in the context of Scheme->C,
but it in no way convinces me that the requirement should be dropped.
I'd be much happier if your compiler had an option that allowed me to
obtain full tail recursion even at a potential expense.
Note that full tail-recursion could be implemented even in your
context in the following horrible but straight forward way. I'm sure
that there are better ways:
There is a large global array used as a temporary to pass arguments to
top-level procedures. There is also an an associated convention to handle
parameter lists longer than the array size.
Top level procedures (including the initial one, corresponding to main
in C) are always called through an interface routine.
This interface routine takes the parameters from the global area and
passes them wherever C procedures expect them (the stack). It should
be no harder to write this than to write the low level primitive for
cwcc that your system has, or whatever you do for closures.
This interface routine also does the equivalent of a C setjmp (I'm
sure your back end supports this C library procedure), and chains
together the longjmp buffers that result from nested calls. The
current buffer is pointed at by a global variable.
When a top-level procedure wants to do a tail-call, it only needs to
place the procedure pointer, argument count, and parameters, in the
global area, and longjmp to the current buffer.
If any of the procedures invoked by the interface routine ever
returns, the interface routine unwinds the longjmp chain once, and
returns to it's caller with the result of the called routine.
∂29-Apr-90 0308 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #356
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 29 Apr 90 03:08:21 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA07280; Sun, 29 Apr 90 06:06:24 EDT
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Sun, 29 Apr 90 06:04:26 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa12843;
29 Apr 90 6:03 EDT
Message-Id: <DIGEST.184.900429.060312.53@MC.LCS.MIT.EDU>
Date: 29 Apr 90 06:03:11 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #356
Scheme Digest #356 29 Apr 90 06:03:11 EDT
Today's Topics:
looking an ftp site for scheme
----------------------------------------------------------------------
Message-ID: <1990Apr26.134048.4571@mentor.com>
Date: 26 Apr 90 13:40:48 GMT
From: Patrick Logan <tektronix!sequent!mntgfx!plogan@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: looking an ftp site for scheme
In article <23728@cs.yale.edu> briscoe-duke@CS.YALE.EDU (Duke Briscoe) writes:
T has an optimizing compiler, and best of all it is available by
anonymous ftp from wheaties.ai.mit.edu (128.52.32.6) in the
pub/t3.1 directory. That directory contains binaries and sources
for T3.1. Currently available versions are for Dec3100(pmax),
Sun4(sparc),Sun3, Vax/Unix, Encore, Hp workstation, Apollo and
Mac/Aux. The online version of the T manual is also there as well
as release notes for T3.0 and T3.1. For Sun and Vax there is a
C/Unix interface to T.
Unfortunately T (at least the version that was on wheaties a few
months ago) will not run on Apollo SR10.1 or later. The problem is the
boot cannot be rebuilt without Apollo operating system sources (unless
you want to derive some constants emprically and insert them by hand
into the assembler source.) The SR10 boot in the distribution is for
SR10.0 which (SR10.0) was failure-prone and quickly made obsolete.
Also unfortunately the T project does not have access to an Apollo
workstation, so it looks like curtains for T on Apollos.
If anyone has converted T to SR10.1 or later, please let me know as
well as the T project. A good thing to do would be to get rid of the
dependency on OS sources!
Meanwhile Scheme->C appears the best, free version of Scheme for
Apollos (using execution time as the determining factor). I hope
someday I'll get to use a supported Scheme like Chez.
--
Patrick Logan uunet!mntgfx!plogan | We have a Peace Dividend?
Mentor Graphics Corp. 8500 SW Creekside Pl | Don't we have to make an
Beaverton, Oregon 97005-7191 | investment first?
------------------------------
End of Scheme Digest
********************
∂30-Apr-90 1239 gyro@piano.reasoning.com tail-recursion
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 30 Apr 90 12:38:14 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA13170; Mon, 30 Apr 90 15:24:54 EDT
Received: from drums.reasoning.com (reasoning.com) by zurich.ai.mit.edu; Mon, 30 Apr 90 15:22:57 edt
Received: from piano.reasoning.com by drums.reasoning.com with SMTP (5.61/25-eef)
id AA11344; Mon, 30 Apr 90 12:23:52 -0700
for rrrs-authors@zurich.ai.mit.edu
Received: by piano.reasoning.com. (4.0/SMI-4.0)
id AA06611; Mon, 30 Apr 90 12:23:20 PDT
Date: Mon, 30 Apr 90 12:23:20 PDT
From: gyro@piano.reasoning.com (Scott Layson Burson)
Message-Id: <9004301923.AA06611@piano.reasoning.com.>
To: RPG@sail.stanford.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Dick Gabriel's message of 26 Apr 90 1355 PDT <18Ortm@SAIL.Stanford.EDU>
Subject: tail-recursion
Date: 26 Apr 90 1355 PDT
From: Dick Gabriel <RPG@sail.stanford.edu>
I could persuade [compiler people] more effectively if I could point to a
larger programmer community, which I could do if I could get some variety
of Scheme into the mainstream, which I could do if I could only get the
definers of the language to allow a mainstream implementation to be
called a Scheme.
Someone conjectured that if we `cave in' on tail call removal, we will
never get these outsiders to adopt it, because, hey, they won their
argument. Well, I cannot think of gentle enough words to use to educate
this someone that the real world of negotiation is not like a trivial war
board game.
My reasoning was not that simplistic. For one thing, I did not think
that a Scheme without tail call removal would have even minimal
acceptance in the Scheme community. Subsequent comments to this list
suggest that while there are purists who would not use such a Scheme,
there are also plenty of people who would. So I stand corrected.
However, (see next paragraph)
Once agreements are made in such a way that you can establish
technical collegiality, additional compromises can be made which will
enable complete implementations.
I am skeptical of this, on technical grounds. I don't see why it should
be any easier to add tail call removal to a fully developed back end
than it would be, for instance, to remove dependence on it from the
Lucid CL implementation. We are all familiar with the phenomenon that
certain properties of a software system have to be designed in at the
beginning of its development; they cannot, in practice, be added later.
Tail call removal certainly seems to me to be a likely candidate for
such a property. If you think otherwise, I am certainly interested to
hear why.
The members of the CL community are returing from the
forest with the arrows of commercial battle in their backs; possibly we
should try to learn what happened to them so as to not make the same
mistakes?
Or possibly we should let them fight our battles for us, since they seem
to be in the position of having to do so anyway:
Oh, by the way, I convinced that compiler backend group to put in tail
call removal. I did it by pointing out that the CL my company supplies to
them will need to use their backends in 1992, and that for my
implementation to work well, tail call removal needs to be supported by
the compiler. One down, 10 to go.
That's a better argument than any having to do with Scheme. I guess we
can't help your campaign much after all. Good luck, though!
Seriously -- my sense of the matter turns on the fact that you are
making this effort anyway. If you weren't, and there were just no
chance of our influencing the compiler folks -- which you argue quite
convincingly there wouldn't be -- then I would be much more inclined to
go the compromise route. But as long as you are making nonzero
progress, Kimosabe, I would prefer we sit tight and await the outcome.
-- Scott
∂01-May-90 0009 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #357
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 May 90 00:08:59 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA23922; Tue, 1 May 90 03:06:04 EDT
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Tue, 1 May 90 03:04:06 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa16555;
1 May 90 2:55 EDT
Message-Id: <DIGEST.184.900501.023114.5@MC.LCS.MIT.EDU>
Date: 1 May 90 02:31:14 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #357
Scheme Digest #357 1 May 90 02:31:14 EDT
Today's Topics:
looking an ftp site for scheme
----------------------------------------------------------------------
Message-ID: <BROMAN.90Apr30120749@schroeder.nosc.mil>
Date: 30 Apr 90 19:07:49 GMT
From: Vincent Broman <trout.nosc.mil!broman@nosc.mil>
To: scheme@mc.lcs.mit.edu
Subject: Re: looking an ftp site for scheme
plogan@mentor.com said:
> Unfortunately T (at least the version that was on wheaties a few
> months ago) will not run on Apollo SR10.1 or later.
My copy of "sr10" t3.1 appears to run some simple tests on sr10.2 .
The version was made about March 1989 and has some fixes added that I found
in some alternate reality which I cannot remember.
Vincent Broman, code 632, Naval Ocean Systems Center, San Diego, CA 92152, USA
Phone: +1 619 553 1641 Internet: broman@nosc.mil Uucp: sdcsvax!nosc!broman
------------------------------
End of Scheme Digest
********************
∂02-May-90 0319 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #358
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 2 May 90 03:19:37 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA13724; Wed, 2 May 90 06:15:41 EDT
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Wed, 2 May 90 06:13:49 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa18506;
2 May 90 6:08 EDT
Message-Id: <DIGEST.184.900502.060131.12@MC.LCS.MIT.EDU>
Date: 2 May 90 06:01:31 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #358
Scheme Digest #358 2 May 90 06:01:31 EDT
Today's Topics:
Semantic domains
----------------------------------------------------------------------
Message-ID: <1862@geocub.greco-prog.fr>
Date: 2 May 90 06:04:23 GMT
From: Pierre Casteran <mcsun!inria!geocub!casteran@uunet.uu.net>
To: scheme@mc.lcs.mit.edu
Subject: Semantic domains
in the draft standard for Scheme, the domain equation for pairs is
Ep = L x L x T
L is the domain of locations and T the domain of booleans, and 'x' stands for
the product.
I understand that a pair is a couple of locations, but not the role played
by the boolean composant.
Idem for vectors and strings.
May somebody help me to get the intuition of this equation ?
P. Casteran
P.S.
Is it possible to get the (TeX?) source of that report. I am interested in
the TeX macros used for the formal semantics part.
Thanks in advance.
------------------------------
End of Scheme Digest
********************
∂03-May-90 0040 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #359
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 3 May 90 00:40:27 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02559; Thu, 3 May 90 03:37:18 EDT
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Thu, 3 May 90 03:35:29 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa15990;
3 May 90 3:19 EDT
Message-Id: <DIGEST.184.900503.024645.16@MC.LCS.MIT.EDU>
Date: 3 May 90 02:46:44 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #359
Scheme Digest #359 3 May 90 02:46:44 EDT
Today's Topics:
LeLisp info request
Scheme and Mathematical Semantics
Scheme in Common Lisp
----------------------------------------------------------------------
Message-ID: <1990May2.021557.24873@Neon.Stanford.EDU>
Date: 2 May 90 02:15:57 GMT
From: Igor Rivin <agate!shelby!neon!news@ucbvax.berkeley.edu>
To: scheme@mc.lcs.mit.edu
Subject: LeLisp info request
I would like some information on LeLisp; to wit:
1. What platforms is it available on?
2. How does one get it?
3. What is it like?
I have heard some positive things about it, but they were from
(self-admitted) biased parties.
PS: I will summarize if there is enough interest.
--
Igor Rivin Wolfram Research, Inc.
rivin@Gang-of-Four.Stanford.EDU or
rivin@wri.com
------------------------------
Message-ID: <354@fbihh.UUCP>
Date: 2 May 90 15:42:20 GMT
From: Martin Weigele <mcsun!unido!fbihh!weigele@uunet.uu.net>
To: scheme@mc.lcs.mit.edu
Subject: Scheme and Mathematical Semantics
As someone who has watched the uprise of Scheme as a semantically
very "clean" dialect of LISP, I understand there must have been quite
some theoretical concern behind its definition.
(Perhaps Scheme could be considered the "Modula-2" of the LISPs,
whereas CommonLisp relates to PL/1 or, even worse, ADA...)
This is reflected by a denotational semantics for parts of scheme
given in the "Revised Report". Does anybody out there know any
further work in this direction since this report was published?
Do the M.I.T. people still work on this?
Martin Weigele, FB Informatik, Univ. Hamburg
------------------------------
Message-ID: <7650@uswat.UUCP>
Date: 2 May 90 19:20:42 GMT
From: Robert Lund <uswat!rml@boulder.colorado.edu>
To: scheme@mc.lcs.mit.edu
Subject: Scheme in Common Lisp
Would someone e-mail me an internet location where I can get a scheme
implementation in Common Lisp (assuming such a thing exists)?
Thanks in advance
Bob Lund
rml@uswest.com
------------------------------
End of Scheme Digest
********************
∂03-May-90 2335 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #360
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 3 May 90 23:22:19 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA21757; Fri, 4 May 90 02:17:52 EDT
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Fri, 4 May 90 02:16:02 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa16169;
4 May 90 2:16 EDT
Message-Id: <DIGEST.184.900504.020235.22@MC.LCS.MIT.EDU>
Date: 4 May 90 02:02:35 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #360
Scheme Digest #360 4 May 90 02:02:35 EDT
Today's Topics:
Scheme in Common Lisp
----------------------------------------------------------------------
Message-ID: <9005031819.AA21130@zurich.ai.mit.edu>
Date: Thu, 3 May 90 14:19:01 edt
From: Jonathan Rees <jar@zurich.ai.mit.edu>
To: uswat!rml@boulder.colorado.edu
CC: scheme@MC.lcs.mit.edu
Subject: Scheme in Common Lisp
There's something called "Pseudoscheme" available by anonymous ftp
from zurich.ai.mit.edu, file pub/pseudo/pseudo-2-7.tar (compressed:
pseudo-2-7.tar.Z). It's not really Scheme because it doesn't handle
tail recursion except where lexically obvious (i.e. loops written
using LETREC, named LET, or internal DEFINE), and it doesn't handle
continuations in general because CALL-WITH-CURRENT-CONTINUATION is
defined in the obvious way in terms of Common Lisp's BLOCK and
RETURN-FROM. Its advantage relative to something more faithful is
that it compiles Scheme to idiomatic Common Lisp, which means that
there is no performance hit relative to CL, and you get to use
whatever debugging support the underlying CL gives you.
------------------------------
End of Scheme Digest
********************
∂05-May-90 1554 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #361
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 5 May 90 15:54:44 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA13396; Sat, 5 May 90 18:49:54 EDT
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Sat, 5 May 90 18:20:25 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa01332;
5 May 90 17:55 EDT
Message-Id: <DIGEST.184.900505.021820.25@MC.LCS.MIT.EDU>
Date: 5 May 90 02:18:20 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #361
Scheme Digest #361 5 May 90 02:18:20 EDT
Today's Topics:
Scheme's case (vs. select)
----------------------------------------------------------------------
Message-ID: <GUTTMAN.90May4113544@darjeeling.mitre.org>
Date: 4 May 90 15:35:44 GMT
From: "Joshua D. Guttman" <snorkelwacker!spdcc!merk!alliant!linus!guttman@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Scheme's case (vs. select)
Why is it that Scheme has the case statement, which does not evaluate its keys?
Wouldn't it be a great deal more useful to have instead a select statement (as
does T) which is exactly the same except that it *does* evaluate its keys?
After all, you can simulate the case using the select by strewing around the
needed quotation marks, but obviously not conversely. And as for smart
compilers, if a compiler does something clever for case, why not have it do
just the same clever thing for select if it observes that all of the keys are
constants?
Josh
------------------------------
End of Scheme Digest
********************
∂06-May-90 0003 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #362
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 6 May 90 00:03:01 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA16083; Sun, 6 May 90 02:53:56 EDT
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Sun, 6 May 90 02:52:05 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa25859;
6 May 90 2:39 EDT
Message-Id: <DIGEST.184.900506.020328.30@MC.LCS.MIT.EDU>
Date: 6 May 90 02:03:28 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #362
Scheme Digest #362 6 May 90 02:03:28 EDT
Today's Topics:
Scheme's case (vs. select)
----------------------------------------------------------------------
Message-ID: <7365@brazos.Rice.edu>
Date: 5 May 90 00:05:18 GMT
From: Dorai Sitaram <titan.rice.edu!dorai@rice.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: Scheme's case (vs. select)
In article <GUTTMAN.90May4113544@darjeeling.mitre.org> guttman@mitre.org (Joshua D. Guttman) writes:
>Why is it that Scheme has the case statement, which does not evaluate its keys?
>Wouldn't it be a great deal more useful to have instead a select statement (as
>does T) which is exactly the same except that it *does* evaluate its keys?
>
>After all, you can simulate the case using the select by strewing around the
>needed quotation marks, but obviously not conversely. And as for smart
>compilers, if a compiler does something clever for case, why not have it do
>just the same clever thing for select if it observes that all of the keys are
>constants?
You're certainly right. I first saw uses of what you call SELECT in
the original paper on engines [1]. They called it EVCASE. It is so
much more useful than plain CASE, especially when you want to make
full use of both Scheme's lexical scoping (to ensure proper hiding)
_and_ CASE-like dispatching (sp? despatching?) constructs.
Similarly, there is an analogous RECORD-EVCASE, which is to
RECORD-CASE, as EVCASE is to CASE.
E.g., let's say we have a slew of tagged messages humming around
inside a lexically cordoned-off portion of code. Dispatching on the
tags of the messages could be done with EVCASE or RECORD-EVCASE.
(record-evcase this-here-tagged-message
[tag1 (msg-par1 ...) larry]
[tag2 (msg-par1 ...) curly]
[tag3 (msg-par1 ...) mo]
...)
The tags can be introduced as
(let ([tag1 (unique)] [tag2 (unique)] ...) <the-whole-caboodle>)
where <the-whole-caboodle> contains all the relevant code using the
tags. Since the tags are created as unique markers (using gensyms or
new conses or boxes or lambdas or whatever) and can only be referred
to by accessing the corresponding variables, we're assured that
nothing EQ? to them can be created by code outside
<the-whole-caboodle>. Hence the latter is safe from spurious messages
(or Trojan horses). Thus, we have a nice way to meaningfully
abbreviate a watertight piece of code.
In sum, both the EV-forms are such charming dears. They can of course
be created by any modest "macro" facility, but it would be nice to
have them recognized by the Scheme standard. Code using them would
then have one less portability issue to worry about, since any
syntactic extension facility used to create them is not portable --
RRRS not having a stance on s.e.'s as yet.
--dorai
[1] Engines build Process Abstractions, Haynes & Friedman, L&FP 1985
------------------------------
End of Scheme Digest
********************
∂08-May-90 0008 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #363
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 8 May 90 00:08:26 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA14760; Tue, 8 May 90 03:07:29 EDT
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Tue, 8 May 90 03:05:11 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa20826;
8 May 90 2:59 EDT
Message-Id: <DIGEST.184.900508.021914.38@MC.LCS.MIT.EDU>
Date: 8 May 90 02:19:14 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #363
Scheme Digest #363 8 May 90 02:19:14 EDT
Today's Topics:
On the standard behavior of "load" (2 messages)
1 message without subject
----------------------------------------------------------------------
Message-ID: <3601@jato.Jpl.Nasa.Gov>
Date: 7 May 90 20:04:19 GMT
From: Brian of ASTD-CP <snorkelwacker!usc!jarthur!elroy.jpl.nasa.gov!jato!granite!brian@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: On the standard behavior of "load"
I would like to start a discussion concer-
ning the Scheme essential procedure "load". The
Scheme definition, R3.99RRS, states that the re-
turn value of "load" is unspecified. However, I
think that "load" should have a specified return
value, and the next few paragraphs explain why
I think so.
With many implementations of Scheme, load returns
#f when the file passed to it is not found, and #t
otherwise. I think this ought to be the standard
behavior of load. In some newer, more "Graphical
User Interface"-oriented implementations of Scheme,
load presents an interactive dialog, asking the
user to pick a file from a list when the given file
is not found. With this behavior, load is not
permitted to return #f and load cannot be used in
unattended programs when it might return #f.
However, there is a very good reason why one might
want load to tell a program that it can't find a
file.
Imagine that a collection of software is divided
into modules and clients. The modules are reusable
abstract data types, procedures, libraries, etc.
The clients are programs built up from the
modules.
It is highly advantageous to maintain the modules
separately from the clients. In particular, clients
should not require knowledge of the directories
modules reside in. Clients should simply refer to
modules by name, as in
(load-module "methods.sch")
(load-module "queues.sch")
(load-module "binary-search.sch")
If clients use only load, then they must have
hard-coded directory names, as in:
(load "MyDisk:Scheme Code:Modules:OOP:methods.sch")
(load "MyDisk:Scheme Code:Modules:OOP:classes:queues.sch")
(load "MyDisk:Scheme Code:Modules:Procedures:binary-search.sch")
and so on. The big maintenance problem occurs when
a module is moved. Using load-module, no clients
need to be changed. Using load, however, all
clients of a module must be manually tracked down
and changed.
The implementation of load-module is simple. It
searches a canonical list of module directories,
using the return value of load to decide whether to
continue or terminate the search.
(define (load-module filename)
(let iter ((canon-dir-list (list
"MyDisk:Scheme Code:Modules:"
"MyDisk:Scheme Code:Modules:OOP:"
"MyDisk:Scheme Code:Modules:OOP:classes:"
"MyDisk:Scheme Code:Modules:Procedures:" )))
(cond
( (null? canon-dir-list) #f )
( (load (string-append (car canon-dir-list) file)) )
( else (iter (cdr canon-dir-list)) ))))
(my real load-module is a little different because
it avoids loading a module more than once, but the
version above illustrates the use of load in
load-module.)
With load-module, if a module directory is changed,
only the canonical directory list, which is in one
place in an initialization file, need be changed.
All static data concerning module locations is hidden
in this single list, rather than being distributed
in multiple copies among the clients, which is
clearly a much inferior organization.
It should be clear that load-module relies on
load's returning #f when a file is not found in a
directory. The ostensibly more user friendly dialog
behavior of load actually forces a developer of
Scheme code to violate separation of module and
client and to pollute client code with extrinsic
information that creates a maintenance headache.
Comments?
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . Brian Beckman . . . . . . . . . . brian@granite.jpl.nasa.gov. . . .
. . meta-disclaimer: every statement in this message is false . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
------------------------------
Message-ID: <9005072245.AA14307@M34-501-16.MIT.EDU>
Date: Mon, 07 May 90 18:45:34 EDT
From: cxy@athena.mit.edu
To: Scheme@lcs.mit.edu
Please remove me from your mailing list. Thank you.
------------------------------
Message-ID: <6149@tekcrl.LABS.TEK.COM>
Date: 7 May 90 21:53:51 GMT
From: Ken Dickey <zephyr.ens.tek.com!tekcrl!tekchips!kend@uunet.uu.net>
To: scheme@mc.lcs.mit.edu
Subject: Re: On the standard behavior of "load"
In article <3601@jato.Jpl.Nasa.Gov> brian@granite.Jpl.Nasa.Gov (Brian of ASTD-CP) writes:
..
>With many implementations of Scheme, load returns
>#f when the file passed to it is not found, and #t
>otherwise. I think this ought to be the standard
>behavior of load.
..
It is certainly desireable to have a portably standard behavior here.
It is also somewhat difficult to achieve.
In some implementations of Scheme, load acts like BEGIN in that it
returns the last value of the storage loaded. Aside from returning
some possibly useful value directly, I think that there are 2 kinds of
information which could be returned:
[A] Was the file/object/whatever found or not.
[B] Was the file/object/whatever successfully loaded, partially
loaded, or not loaded?
Once error conditions are considered, the question of what LOAD
returns becomes more complex--complex enough that there has not yet
evolved a concensus for a standard Scheme error system [I would
certainly like one!]. I believe that it will be difficult to resolve
the question of what LOAD should return in the absence of a standard
interface for failure/error handling. What if there is no error
handling mechanism? Also to be considered are behaviors which differ
in loading compiled vs source files.
Possibilities suggested:
Have [possibly optional] success and failure continuations passed in,
Call an `system' error handler in a specified way,
Pass in a function to be called on error,
etc.
Adding parameters, however, gets into parameter order and issues of
first-class environments and whether LOAD takes an environment
parameter.
Given that LOAD is very system dependent, the prudent approach is to
hide it abstractly away somewhere with other system dependent code.
-Ken
------------------------------
End of Scheme Digest
********************
∂09-May-90 0003 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #364
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 9 May 90 00:02:19 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA04915; Wed, 9 May 90 03:00:44 EDT
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Wed, 9 May 90 02:58:49 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa15146;
9 May 90 2:45 EDT
Message-Id: <DIGEST.184.900509.020425.43@MC.LCS.MIT.EDU>
Date: 9 May 90 02:04:25 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #364
Scheme Digest #364 9 May 90 02:04:25 EDT
Today's Topics:
Where is xscheme?
On the standard behavior of "load" (2 messages)
scheme games
Non-local variables
Semantic domains
----------------------------------------------------------------------
Message-ID: <1523@viewlog.UUCP>
Date: 7 May 90 19:36:54 GMT
From: Josh Marantz <snorkelwacker!usc!samsung!cg-atla!viewlog!josh@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Where is xscheme?
Where is the internet archive for xscheme? How good is the latest version?
Is David Betz still working on it?
--
Joshua Marantz
Viewlogic Systems, Inc.
viewlog!josh@cg-atla.agfa.com
Why not pass the time by playing a game of solitaire?
------------------------------
Message-ID: <1324@tub.UUCP>
Date: 8 May 90 10:51:50 GMT
From: Oliver Laumann <eru!luth!sunic!mcsun!unido!tub!net@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: On the standard behavior of "load"
In article <3601@jato.Jpl.Nasa.Gov> brian@granite.Jpl.Nasa.Gov (Brian of ASTD-CP) writes:
> I would like to start a discussion concerning the Scheme essential
> procedure "load". The Scheme definition, R3.99RRS, states that the
> return value of "load" is unspecified. However, I think that "load"
> should have a specified return value [...]
I don't think "load" should have a return value which indicates success
or error. When the file could not be opened or some other error condition
occurred, it should simply "signal an error" (whatever this means) like
all other primitive procedures do in case of an error condition.
After all, "write" doesn't return #f either when a write error occurred
(disk full or whatever).
In addition, Scheme implementations could provide an "(autoload 'foo)"
function which causes a file "foo.scm" or so to be loaded automatically
the next time the symbol foo is evaluated but not bound. In this case one
wouldn't be able to test the return value of the call to "load" anyway.
I'm sure most Scheme implementations allow you to catch and handle an
error anyway, for instance by "hooking" into the "system error handler"
or by redefining the error handler. In Elk, for instance, one can
easily write an equivalent to the Lisp "errset" which can be wrapped
around the call to "load" to test whether it failed.
> It is highly advantageous to maintain the modules separately from the
> clients. In particular, clients should not require knowledge of the
> directories modules reside in. Clients should simply refer to modules
> by name, as in (load-module "methods.sch") [...]
> The implementation of load-module is simple. It searches a canonical
> list of module directories, using the return value of load to decide
> whether to continue or terminate the search.
I think this can be handled by the more general concept of a "load
path". Some (many?) Scheme and Lisp implementations maintain a list
of directories that are searched for the file that is specified in
the call to "load".
In Elk, for instance, "load-path" is a variable bound in the initial
environment; the initial value is a list of directories where the
Scheme system files and extensions can be found plus the current
directory. Applications can bind the "load-path" to a different
list of directories or add the directories where the applications'
modules reside.
--
Oliver Laumann, Technical University of Berlin, Germany.
pyramid!tub!net net@TUB.BITNET net@tub.cs.tu-berlin.de
------------------------------
Message-ID: <9005081621.AA13048@mtecv2.mty.itesm.mx>
Date: Tue, 8 May 90 10:21:15 CST
From: Juan Gabriel Ruiz Pinto <jgabriel@mtecv2.mty.itesm.mx>
To: scheme@mc.lcs.mit.edu
Subject: scheme games
Hi, actually I'm working in Scheme in an Artificial Intelligence
class, and I need some examples of competitive games made in Scheme.
Can anybody tell me if I can get them via ftp or mail?
Thank's in advance!
***** Greetings from Mexico! *****
Juan Gabriel Ruiz Pinto Internet:
Ing. Sistemas Electronicos jgabriel@mtecv2.mty.itesm.mx
I.T.E.S.M. Campus Monterrey
------------------------------
Message-ID: <7490@brazos.Rice.edu>
Date: 8 May 90 16:47:19 GMT
From: Dorai Sitaram <titan.rice.edu!dorai@rice.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: On the standard behavior of "load"
In article <3601@jato.Jpl.Nasa.Gov> brian@granite.Jpl.Nasa.Gov (Brian of ASTD-CP) writes:
>I would like to start a discussion concer-
>ning the Scheme essential procedure "load". The
>Scheme definition, R3.99RRS, states that the re-
>turn value of "load" is unspecified. However, I
>[...]
>With many implementations of Scheme, load returns
>#f when the file passed to it is not found, and #t
>otherwise. I think this ought to be the standard
>behavior of load. [...]
Wouldn't you be satisfied with just `file-exists?'? Almost every
Scheme I've come across provides this procedure -- though RRRS doesn't
include it. Obviously, `file-exists?' and the unspecified-returning
`load' provide the capability you desire (load-module, etc.).
(define load1
(lambda (f) (if (file-exists? f) (begin (load f) #t) #f)))
(NB: The #f/#t `load' doesn't make `file-exists?' superfluous. The
latter provides the ability to say that a file exists without having
to load it too.)
--dorai
------------------------------
Message-ID: <1990May8.205719.2014@sun.soe.clarkson.edu>
Date: 8 May 90 20:57:19 GMT
From: Jason Coughlin <mcgill-vision!snorkelwacker!usc!zaphod.mps.ohio-state.edu!rpi!image.soe.clarkson.edu!jk0@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Non-local variables
Hi. I've got a short little example which creates a non-local
variable to implement a simple little counter. In my implementation of
Scheme, I create it like this:
(let ([a 0])
(define counter
(lambda ()
(set! a (+ a 1))
a
)
)
)
PC-Scheme barfs on this complaining about an illegal letrec
syntax. Both PC-Scheme and my Scheme allow the example in Dybvig's
book, _The Scheme Programming Language_:
(define counter
(let ([a 0])
(lambda ()
(set! a (+ a 1))
a
)
)
)
Am I missing something important here?
--
Jason Coughlin ( jk0@sun.soe.clarkson.edu , jk0@clutx )
"Every jumbled pile of person has a thinking part that wonders what the
part that isn't thinking isn't thinking of." -- They Might Be Giants
"If you read the _TV Guide_, then there's no need for a TV." -- Lost Boys
------------------------------
Message-ID: <122192@ti-csl.csc.ti.com>
Date: 3 May 90 19:32:31 GMT
From: John Gateley <mintaka!ogicse!uwm.edu!cs.utexas.edu!ut-emx!infotel!smunews!ti-csl!m2!gateley@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: Semantic domains
In article <1862@geocub.greco-prog.fr> casteran@geocub.greco-prog.fr (Pierre Casteran) writes:
>in the draft standard for Scheme, the domain equation for pairs is
>Ep = L x L x T
>I understand that a pair is a couple of locations, but not the role played
>by the boolean composant.
The boolean component is used for read only data:
I cannot find the section of the semantics which
constructs data (it may have been omitted), but
any data created by quote can be considered read-only, and
is not modifiable by any mutation procedures.
Check out the definition of set-car in the semantics.
John
gateley@m2.csc.ti.com
------------------------------
End of Scheme Digest
********************
∂10-May-90 0026 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #365
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 10 May 90 00:25:59 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA26273; Thu, 10 May 90 03:24:57 EDT
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Thu, 10 May 90 03:23:02 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa08008;
10 May 90 3:17 EDT
Message-Id: <DIGEST.184.900510.023513.48@MC.LCS.MIT.EDU>
Date: 10 May 90 02:35:13 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #365
Scheme Digest #365 10 May 90 02:35:13 EDT
Today's Topics:
Non-local variables (3 messages)
How do you determine if a procedure is defined?
On the standard behavior of "load"
----------------------------------------------------------------------
Message-ID: <7478@accuvax.nwu.edu>
Date: 9 May 90 17:40:10 GMT
From: Bruce Krulwich <snorkelwacker!usc!cs.utexas.edu!mailrus!accuvax.nwu.edu!krulwich@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: Non-local variables
In article <1990May8.205719.2014@sun.soe.clarkson.edu>, jk0@image (Jason
Coughlin) writes:
> Hi. I've got a short little example which creates a non-local
>variable to implement a simple little counter. In my implementation of
>Scheme, I create it like this:
>
>(let ([a 0])
> (define counter
> (lambda ()
> (set! a (+ a 1))
> a
> )
> )
>)
>
> PC-Scheme barfs on this complaining about an illegal letrec syntax.
I think that the problem is that DEFINE's that are not at the top-level are
considered by Scheme (but not T or CL) to be local definitions like
LETREC's. Probably the code you give above is transformed into a LET
containing a body-less LETREC, which is illegal.
This is an issue that has been discussed before. Basically, the treatment
of internal DEFINE's as local definitions makes it impossible to have
static locally-scoped variables that span across procedures. (Having
static variables for one procedure can be achieved as you showed later in
your message.) Having internal DEFINE's result in local definitions
doesn't add any power, because they're identical in meaning to LETREC, but
to some people this seems more semantically correct than simply having all
DEFINE's result in top-level definitions. Of course, another issue for
many people is that changing the meaning would make old code incorrect.
Bruce Krulwich
Institute for the Learning Sciences
krulwich@ils.nwu.edu
------------------------------
Message-ID: <MAC.90May9161711@k9.cad.mcc.com>
Date: 9 May 90 21:17:11 GMT
From: Mac Michaels <cs.utexas.edu!milano!cadillac!mac@yale-zoo.arpa>
To: scheme@mc.lcs.mit.edu
Subject: How do you determine if a procedure is defined?
Using only essential Scheme procedures, I have not been able to determine if
a non-essential Scheme procedure is already defined.
PROCEDURE? fails with an undefined symbol error when given a non-existent
symbol name. If you quote the argument to PROCEDURE? it always returns #F.
To attempt to get around this with SYMBOL? is also futile. SYMBOL? also
gets an undefined symbol error when given a non-existent symbol name and
always returns #T when given a quoted name.
Why is it needed? I am trying to write a file that can be loaded into any
Scheme that will add some of the missing procedure definitions. This will
allow me to easily port code to a number of different Scheme
implementations. I do not want to replace the implementation's
non-essential function if it already exists.
Some ways that this problem could be addressed are:
Add a special form (say DEFINED?) that returns #T if it's unquoted
argument exists.
Add a procedure to return the Scheme system name and version number.
--
USPS: Mac Michaels, 3500 West Balcones Center Dr., Austin,TX 78759
ARPA: mac@mcc.com TELE: (512) 338-3509 FAX: (512) 338-3600
UUCP: {uunet,harvard,gatech,pyramid}!cs.utexas.edu!milano!cadillac!mac
:-)))))))) She had so many chins, she looked like a piece of Lisp code!
------------------------------
Message-ID: <7502@odin.corp.sgi.com>
Date: 9 May 90 23:53:56 GMT
From: Jonathan Shapiro <sgi!shinobu!odin!thebeach.wpd.sgi.com!shap@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: On the standard behavior of "load"
What file-exists *doesn't* do is guarantee that a subsequent load will
succeed, because the file could get deleted.
The underlying issue here is that the scheme designers haven't yet
agreed on an error handling mechanism. It would be unambiguously wrong
to specify one in the standard if it isn't right.
Jonathan Shapiro
Silicon Graphics, Inc.
------------------------------
Message-ID: <1990May10.003231.3064@calgary.uucp>
Date: 10 May 90 00:32:31 GMT
From: Andrew Ginter <snorkelwacker!apple!usc!zaphod.mps.ohio-state.edu!van-bc!ubc-cs!calgary!cpsc!gintera@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: Non-local variables
In article <7478@accuvax.nwu.edu>, krulwich@ils.nwu.edu (Bruce Krulwich) writes:
> This is an issue that has been discussed before. Basically, the treatment
> of internal DEFINE's as local definitions makes it impossible to have
> static locally-scoped variables that span across procedures. (Having
> static variables for one procedure can be achieved as you showed later in
> your message.)
It seems to me that the variable "a" below is a locally scoped variable
which spans procedures...
(define dummy
(let ((a 0))
(list (lambda () (set! a (+ 1 a)) a)
(lambda () (set! a (- 1 a)) a))))
(define count-up (car dummy))
(define count-down (cadr dummy))
Andrew Ginter, 403-282-2984, gintera@CPSC.UCALGARY.CA, Ginter@UNCAMULT.BITNET
------------------------------
Message-ID: <1990May9.222152.27950@Neon.Stanford.EDU>
Date: 9 May 90 22:21:52 GMT
From: Max Hailperin <eagle!amelia!eos!shelby!neon!max@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: Non-local variables
In article <7478@accuvax.nwu.edu> krulwich@ils.nwu.edu (Bruce Krulwich) writes:
>In article <1990May8.205719.2014@sun.soe.clarkson.edu>, jk0@image (Jason
>Coughlin) writes: ...
>>(let ([a 0])
>> (define counter
>> (lambda ()
>> (set! a (+ a 1))
>> a
>> )
>> )
>> ... PC-Scheme barfs on this complaining about an illegal letrec syntax.
>I think that the problem is that DEFINE's that are not at the top-level are
>considered by Scheme (but not T or CL) to be local definitions like
>LETREC's. Probably the code you give above is transformed into a LET
>containing a body-less LETREC, which is illegal.
Yes, this is what's wrong. However, the syntax error is in fact discernable
without resorting to the explanation of the rewriting into a letrec (though
you wouldn't understand then why the error message mentions letrec). The
syntax for let says it takes a "body" which is defined as zero or more
definitions followed by one or more expressions. Hence, the code above
is illegal because there is no expression in the body of the let, just
a definition.
While I'm at it, I'd like to chip in my two cents on some of the other
issues raised:
>This is an issue that has been discussed before. Basically, the treatment
>of internal DEFINE's as local definitions makes it impossible to have
>static locally-scoped variables that span across procedures. ...
This isn't true, though it requires what some consider an unaesthetic
idiom. What you do is define the procedure names as some placeholder, e.g.
#f, and then use set! within the appropriate lexical scope to mutate them
to name the actual procedures, made with lambda. The main disadvantage
of this idiom, from my perspective, is that it makes the procedure names
mutable, which causes compilers and people alike to handle them gingerly.
On the other hand, I don't know of any better alternative -- see the below.
>Having internal DEFINE's result in local definitions
>doesn't add any power, because they're identical in meaning to LETREC,
Right, that's why R3RS makes them optional. On the other hand, while
they don't add anything semantically, they can be nice syntactically
by helping prevent your code from gradually drifting off the right edge
of the page.
>but
>to some people this seems more semantically correct than simply having all
>DEFINE's result in top-level definitions. Of course, another issue for
>many people is that changing the meaning would make old code incorrect.
The issue isn't "semantic correctness," but rather that we (yes, I am one
of the "some people") don't accept the premise that there is a unique
top-level. Real systems frequently have levels of varying degrees of
top-ness, and it's hard to know just where the programmer intended a
definition to be installed, if not the current scope. Aside from
this, the right level for a procedure might not be a top-level at
all, in any sense. Take the case of two procedures which need to
share some private state and should themselves only be visible in
a restricted part of the program. This works fine using the set!
approach, but can't be handled by the define-is-always-top-level
approach.
------------------------------
End of Scheme Digest
********************
∂10-May-90 2355 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #366
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 10 May 90 23:55:39 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA19703; Fri, 11 May 90 02:50:53 EDT
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Fri, 11 May 90 02:48:42 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa02405;
11 May 90 2:37 EDT
Message-Id: <DIGEST.184.900511.020304.5@MC.LCS.MIT.EDU>
Date: 11 May 90 02:03:03 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #366
Scheme Digest #366 11 May 90 02:03:03 EDT
Today's Topics:
Advice to start learning
How do you determine if a procedure is defined?
seeking loop macro for TI scheme
----------------------------------------------------------------------
Message-ID: <00936727.37AF7EA0@BINAH.CC.BRANDEIS.EDU>
Date: Thu, 10 May 90 02:39:31 EDT
From: mintaka!chaos.cs.brandeis.edu!OURY%BINAH.CC.BRANDEIS.EDU@bloom-beacon.mit.edu
To: scheme@mc.lcs.mit.edu
Subject: Advice to start learning
Greetings,
I am interested in learning scheme and would appreciate any
evaluations of either books which teach the langauge and/or versions
available via ftp for either Sun3/Unix or Vax/VMS. I already have
'Structure and Interpretation of Computer Programs' by Abelson and
Sussman, and 'The T Programming Language' by Slade. Also any sample
programs would be welcome. I'll summarize if there is other interest.
Thanks in advance. David Oury.
. . . . . . . .. . . . . .. . . . .
Address: oury@brandeis.bitnet Disclaimer: Just me, noone else.
Remember, no matter where you are, you're there.
. . . ... . . . .. . . ... . .
------------------------------
Message-ID: <1330@tub.UUCP>
Date: 10 May 90 16:29:41 GMT
From: Oliver Laumann <cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!ira.uka.de!fauern!tub!net@yale-zoo.arpa>
To: scheme@MC.lcs.mit.edu
Subject: Re: How do you determine if a procedure is defined?
In article <MAC.90May9161711@k9.cad.mcc.com> mac@mcc.com (Mac Michaels) writes:
> Some ways that this problem could be addressed are:
>
> Add a special form (say DEFINED?) that returns #T if it's unquoted
> argument exists.
Elk has a predicate "bound?" which, when applied to a symbol, returns
#t iff the variable named by the symbol is bound in the current
environment.
I think T has a "bound?" predicate, too; at least a "grep" on the
sources says so.
I'm sure C-Scheme has a similar function as well (it must, since it
has virtually everything :-)
XScheme has a "bound?" predicate similar to the one in Elk.
Regards,
--
Oliver Laumann net@TUB.BITNET net@tub.cs.tu-berlin.de net@tub.UUCP
------------------------------
Message-ID: <5349@itivax.iti.org>
Date: 10 May 90 21:42:04 GMT
From: "David H. West" <ox.com!itivax!dhw@yale-zoo.arpa>
To: scheme@mc.lcs.mit.edu
Subject: seeking loop macro for TI scheme
the subject line says it all ...
-David West dhw@iti.org
------------------------------
End of Scheme Digest
********************
∂12-May-90 2347 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #367
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 12 May 90 23:47:51 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA13810; Sun, 13 May 90 02:47:57 EDT
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Sun, 13 May 90 02:45:45 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa01869;
13 May 90 2:36 EDT
Message-Id: <DIGEST.184.900513.021711.5@MC.LCS.MIT.EDU>
Date: 13 May 90 02:17:11 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #367
Scheme Digest #367 13 May 90 02:17:11 EDT
Today's Topics:
xlisp manual in latex format
X Windows - MIT Scheme
----------------------------------------------------------------------
Message-ID: <21007@boulder.Colorado.EDU>
Date: 11 May 90 22:19:17 GMT
From: Dirk Grunwald <grunwald@boulder.colorado.edu>
To: scheme@mc.lcs.mit.edu
Subject: xlisp manual in latex format
Some time ago, I asked for an xscheme manual in latex format. Getting
no answers, I converted xscheme.doc to xscheme.tex, which is available
via anonymous ftp from foobar.colorado.edu. It prints in 15 pages,
including a table of contents and an index, 11 pages w/o.
I have also forgotten from whence I picked up xscheme. Does anyone
know of its true home? I looked on uunet.uu.net & found an ``arc''
file there, but am looking for something more unix-ish.
Dirk Grunwald -- Univ. of Colorado at Boulder (grunwald@foobar.colorado.edu)
(grunwald@boulder.colorado.edu)
------------------------------
Message-ID: <847@vice2utc.chalmers.se>
Date: 12 May 90 19:41:19 GMT
From: Urban Boqvist <snorkelwacker!usc!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!chalmers!afs-news!hacke5!d7urbbo@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: X Windows - MIT Scheme
I'm quite new to this group so maybe this question has been
answered before.
Anyway, I've heard of some sort of X toolkit for MIT Scheme. Does this
or anything like it exist? Is it included in the standard distribution?
If not, does anybody know a site where I might get it?
I'm also interested in some sort of User's Manual for MIT Scheme, there
doesn't seem to be one on my system.
Please answer by email, or if you think it is of general
interest, on the net.
Thanks,
Chalmers ! d7urbbo@dtek.chalmers.se ! ... actually, if any REAL programmer is
U of T ! Urban Boquist ! around at 9 a.m., it's because he's
Gothenburg! Sweden ! been up all night.
Chalmers ! d7urbbo@dtek.chalmers.se ! ... actually, if any REAL programmer is
U of T ! Urban Boquist ! around at 9 a.m., it's because he's
Gothenburg! Sweden ! been up all night.
------------------------------
End of Scheme Digest
********************
∂13-May-90 2325 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #368
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 13 May 90 23:25:00 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA22913; Mon, 14 May 90 02:25:00 EDT
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Mon, 14 May 90 02:22:46 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa25367;
14 May 90 2:22 EDT
Message-Id: <DIGEST.184.900514.020219.9@MC.LCS.MIT.EDU>
Date: 14 May 90 02:02:19 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #368
Scheme Digest #368 14 May 90 02:02:19 EDT
Today's Topics:
ELK and scheme as an extension language (4 messages)
----------------------------------------------------------------------
Message-ID: <HAM.90May12214626@Neon.Stanford.EDU>
Date: 13 May 90 04:46:26 GMT
From: "Peter R. Ham" <ptolemy!eos!shelby!neon!neon.Stanford.EDU!ham@AMES.ARC.NASA.GOV>
To: scheme@mc.lcs.mit.edu
Subject: ELK and scheme as an extension language
I'm very interested in ELK and this issue. Does anyone have any
recent references to papers on ELK or other extension languages.
I'd like references after 1987.
I've only seen only place to ftp ELF from on this group.
And that network has been unreachable. Anybody else have it?
--
Peter Ham PO Box 3430 (h)(415) 322-4390
MS Computer Science Student Stanford, CA ham@cs.stanford.edu
Stanford University 94309 (o)(415) 723-2067
------------------------------
Message-ID: <1334@tub.UUCP>
Date: 13 May 90 15:55:09 GMT
From: Oliver Laumann <eru!luth!sunic!mcsun!unido!tub!net@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: Elk and scheme as an extension language
In article <HAM.90May12214626@Neon.Stanford.EDU> ham@Neon.Stanford.EDU (Peter R. Ham) writes:
> Does anyone have any recent references to papers on ELK or other extension
> languages. I'd like references after 1987.
I'm interested in papers about extension languages, too, since I'm
currently writing my thesis about the usage of functional programming
languages as extension languages. I'm also interested in pointers to
existing applications with Scheme and/or Lisp-like extension languages,
since part of the thesis will be a survey of such languages.
Papers on Elk (documentation) are part of the Elk distribution.
> I've only seen only place to ftp ELF [sic] from on this group.
> And that network has been unreachable. Anybody else have it?
I can mail you a copy if everything else fails. By the way, if someone
at a US Internet site is willing to make the current version of Elk
available on their site for FTP access, I'd like to hear from you.
Mailing dozens of copies of Elk to the US puts quite a strain on the
rusty German e-mail networks (and on our university's budget as well).
Thanks,
--
Oliver Laumann, Technical University of Berlin, Germany.
pyramid!tub!net net@TUB.BITNET net@tub.cs.tu-berlin.de
------------------------------
Message-ID: <HAM.90May13111329@Neon.Stanford.EDU>
Date: 13 May 90 18:13:29 GMT
From: "Peter R. Ham" <agate!shelby!neon!neon.Stanford.EDU!ham@ucbvax.berkeley.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: Elk and scheme as an extension language
Please mail it to me. Nobody else has replied.
I can place the sources on labrea.stanford.edu for
public access by anonymous ftp.
--
Peter Ham PO Box 3430 (h)(415) 322-4390
MS Computer Science Student Stanford, CA ham@cs.stanford.edu
Stanford University 94309 (o)(415) 723-2067
------------------------------
Message-ID: <HAM.90May13115338@Neon.Stanford.EDU>
Date: 13 May 90 18:53:38 GMT
From: "Peter R. Ham" <agate!shelby!neon!neon.Stanford.EDU!ham@ucbvax.berkeley.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: Elk and scheme as an extension language
The latest references I have on extension languages
is a Phd Thesis from CMU dated June 1988.
Do you already have it? I imagine that you do.
It's called "Programmable Command Languages for
Window Systems" by Richard Joel Cohn.
It's number is CMU-CS-88-139
The thesis is about using a version of Xlisp
as the extension language in Andrew Toolkit
related applications. It has a pretty
good bibliography.
Can you send me your current bibliography?
I'll proof your thesis if you'd like.
How many people are currently using ELK?
What's its effeciency like? Can a
compiler like Scheme->C be used on ELK
code and dynamically loaded in?
How's the Xtoolkit user interface?
I'm considering using ELK in a real application.
--
Peter Ham PO Box 3430 (h)(415) 322-4390
MS Computer Science Student Stanford, CA ham@cs.stanford.edu
Stanford University 94309 (o)(415) 723-2067
------------------------------
End of Scheme Digest
********************
∂14-May-90 2342 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #369
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 14 May 90 23:42:29 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA12835; Tue, 15 May 90 02:38:00 EDT
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Tue, 15 May 90 02:35:41 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa00486;
15 May 90 2:34 EDT
Message-Id: <DIGEST.184.900515.023248.15@MC.LCS.MIT.EDU>
Date: 15 May 90 02:32:48 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #369
Scheme Digest #369 15 May 90 02:32:48 EDT
Today's Topics:
Non-local variables (2 messages)
----------------------------------------------------------------------
Message-ID: <PK.90May14122334@korppi.tut.fi>
Date: 14 May 90 09:23:34 GMT
From: Kellom{ki Pertti <bbn.com!usc!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!tut!pk@eddie.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: Non-local variables
>>>>> On 10 May 90 00:32:31 GMT, gintera@cpsc.ucalgary.ca (Andrew Ginter) said:
Andrew> It seems to me that the variable "a" below is a locally scoped variable
Andrew> which spans procedures...
Andrew> (define dummy
Andrew> (let ((a 0))
Andrew> (list (lambda () (set! a (+ 1 a)) a)
Andrew> (lambda () (set! a (- 1 a)) a))))
Andrew> (define count-up (car dummy))
Andrew> (define count-down (cadr dummy))
Which in turn is roughly equivalent to the following more traditional
version:
(define (dummy proc)
(define a 0)
(define (count-up) (set! a (+ 1 a)) a)
(define (count-down) (set! a (- 1 a)) a)
(case proc
((count-up) count-up)
((count-down) count-down)))
(define count-up (dummy 'count-up))
(define count-down (dummy 'count-down))
Both versions create a composite object (a list vs. a procedure) that
contains the procedures with a common local variable. I kinda like
Andrew's version, though, because of its creative use of procedures as data
objects.
--
Pertti Kellom\"aki (TeX format) # These opinions are mine,
Tampere Univ. of TeXnology # ALL MINE !
Software Systems Lab # (but go ahead and use them, if you like)
------------------------------
Message-ID: <PK.90May14154806@kaarne.tut.fi>
Date: 14 May 90 12:48:06 GMT
From: Kellom{ki Pertti <bu.edu!xylogics!samsung!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!tut!pk@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: Non-local variables
>>>>> On 14 May 90 09:23:34 GMT, pk@tut.fi (Kellom{ki Pertti) said:
>>>>> On 10 May 90 00:32:31 GMT, gintera@cpsc.ucalgary.ca (Andrew Ginter) said:
Andrew> It seems to me that the variable "a" below is a locally scoped variable
Andrew> which spans procedures...
Andrew> (define dummy
Andrew> (let ((a 0))
Andrew> (list (lambda () (set! a (+ 1 a)) a)
Andrew> (lambda () (set! a (- 1 a)) a))))
Andrew> (define count-up (car dummy))
Andrew> (define count-down (cadr dummy))
pk> Which in turn is roughly equivalent to the following more traditional
pk> version:
pk> (define (dummy proc)
pk> (define a 0)
pk> (define (count-up) (set! a (+ 1 a)) a)
pk> (define (count-down) (set! a (- 1 a)) a)
pk> (case proc
pk> ((count-up) count-up)
pk> ((count-down) count-down)))
pk> (define count-up (dummy 'count-up))
pk> (define count-down (dummy 'count-down))
pk> Both versions create a composite object (a list vs. a procedure) that
pk> contains the procedures with a common local variable. I kinda like
pk> Andrew's version, though, because of its creative use of procedures as data
pk> objects.
The above is not quite correct, as mob@media-lab.media.mit.edu pointed out:
mario> From: mob@media-lab.media.mit.edu
mario> To: pk@tut.fi
mario> Subject: Re: Non-local variables
mario> Date: Mon, 14 May 90 08:13:20 EDT
mario> The essential difference between his function and yours is that his
mario> "count-up" and "count-down" programs have the same "a" bound, while
mario> yours have a different "a". That's not "roughly equivalent" in my
mario> book.
mario> --Mario
A (hopefully) correct version is given below. The point is of course
that the environment in which a, count-up and count-down are defined should only
be created once.
(define dummy
(letrec ((a 0)
(count-up (lambda () (set! a (+ 1 a))))
(count-down (lambda () (set! a (- 1 a)))))
(lambda (proc)
(case proc
((count-up) count-up)
((count-down) count-down)))))
(define count-up (dummy 'count-up))
(define count-down (dummy 'count-down))
The way count-up and count-down count is incidentally interesting ;-)
> (count-up)
1
> (count-up)
2
> (count-up)
3
> (count-up)
4
> (count-up)
5
> (count-up)
6
> (count-up)
7
>
(count-up)
8
> (count-up)
9
> (count-up)
10
> (count-down)
-9
> (count-down)
10
> (count-down)
-9
> (count-down)
10
> (count-down)
-9
> (count-up)
-8
--
Pertti Kellom\"aki (TeX format) # These opinions are mine,
Tampere Univ. of TeXnology # ALL MINE !
Software Systems Lab # (but go ahead and use them, if you like)
------------------------------
End of Scheme Digest
********************
∂15-May-90 2340 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #370
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 15 May 90 23:39:58 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA13499; Wed, 16 May 90 02:39:04 EDT
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Wed, 16 May 90 02:36:47 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa05973;
16 May 90 2:25 EDT
Message-Id: <DIGEST.184.900516.020347.21@MC.LCS.MIT.EDU>
Date: 16 May 90 02:03:46 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #370
Scheme Digest #370 16 May 90 02:03:46 EDT
Today's Topics:
Elk and scheme as an extension language
Non-local variables
----------------------------------------------------------------------
Message-ID: <1335@tub.UUCP>
Date: 15 May 90 16:29:40 GMT
From: Oliver Laumann <mcsun!unido!fauern!tub!net@uunet.uu.net>
To: scheme@mc.lcs.mit.edu
Subject: Re: Elk and scheme as an extension language
In article <HAM.90May13115338@Neon.Stanford.EDU> ham@Neon.Stanford.EDU (Peter R. Ham) writes:
> What's its [Elk's] effeciency like?
It's as efficient as an interpreter that doesn't compile into an
intermediate language (byte code) can be made. That is, it's less
efficient than, for instance, XScheme (which does byte compile).
Anyway, it's efficient enough to be used as an extension language,
which is what Elk was written for in the first place (as opposed to
`yet another Scheme implementation').
> How's the Xtoolkit user interface?
Fine, thank you :-)
Its functionality is pretty much similar to that of the C language
interface to the intrinsics. However, you can't define new widget
types in Elk, just use existing widget sets (currently the Athena, HP,
and Motif widget sets). One of our CS students recently wrote a table
editor for X11 with `tbl' back-end entirely in Elk (based on the Xt and
Motif integration of Elk) as his semester assignment, so the Xt
interface seems to be usable.
> I'm considering using ELK in a real application.
Here Elk is being used as the extension language and/or user interface
implementation language of several `real' applications, among them an
ODA-based document system (WYSIWYG editor), an X.500 implementation,
and some other projects of which I don't know any details.
Regards,
--
Oliver Laumann net@TUB.BITNET net@tub.cs.tu-berlin.de net@tub.UUCP
------------------------------
Message-ID: <2493@skye.ed.ac.uk>
Date: 15 May 90 16:41:25 GMT
From: Jeff Dalton <mcsun!ukc!edcastle!aiai!jeff@uunet.uu.net>
To: scheme@mc.lcs.mit.edu
Subject: Re: Non-local variables
In article <1990May9.222152.27950@Neon.Stanford.EDU> max@Neon.Stanford.EDU (Max Hailperin) writes:
>In article <7478@accuvax.nwu.edu> krulwich@ils.nwu.edu (Bruce Krulwich) writes:
>The issue isn't "semantic correctness," but rather that we (yes, I am one
>of the "some people") don't accept the premise that there is a unique
>top-level. Real systems frequently have levels of varying degrees of
>top-ness, and it's hard to know just where the programmer intended a
>definition to be installed, if not the current scope.
It's not clear to me that uniqueness of top-level actually is a
premise. It would be a problem if it weren't clear which level
was meant, but real systems containing non-standard extensions to
Scheme ought to be able to specify something reasonable.
It's never possible in any case for the system to know what the
programmer intended. The question is whether we could specify
something sufficiently non-confusing so that programmers won't
often be getting it wrong.
>Aside from this, the right level for a procedure might not be a top-level
>at all, in any sense.
True, but then you can use set!. What it comes down, I think, is
that some people like one one way of using non-top-level defines
and some like another.
------------------------------
End of Scheme Digest
********************
∂17-May-90 0035 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #371
Received: from life.ai.mit.edu ([128.52.32.80]) by SAIL.Stanford.EDU with TCP; 17 May 90 00:35:28 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA01981; Thu, 17 May 90 03:33:17 EDT
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Thu, 17 May 90 03:30:55 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa11035;
17 May 90 3:12 EDT
Message-Id: <DIGEST.184.900517.024916.27@MC.LCS.MIT.EDU>
Date: 17 May 90 02:49:15 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #371
Scheme Digest #371 17 May 90 02:49:15 EDT
Today's Topics:
Non-local variables
----------------------------------------------------------------------
Message-ID: <7801@accuvax.nwu.edu>
Date: 16 May 90 15:47:45 GMT
From: Bruce Krulwich <mailrus!accuvax.nwu.edu!krulwich@uunet.uu.net>
To: scheme@mc.lcs.mit.edu
Subject: Re: Non-local variables
In article <2493@skye.ed.ac.uk>, jeff@aiai (Jeff Dalton) writes:
>>Aside from this, the right level for a procedure might not be a top-level
>>at all, in any sense.
>
>True, but then you can use set!. What it comes down, I think, is
>that some people like one one way of using non-top-level defines
>and some like another.
Not quite. I would say rather that some want one function out of two
syntactic forms and some want two functions out of two syntactic forms.
Bruce
------------------------------
End of Scheme Digest
********************
∂18-May-90 2146 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #372
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 18 May 90 21:46:31 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA19273; Fri, 18 May 90 07:11:10 EDT
Received: from life.ai.mit.edu (life.ai.mit.edu) by zurich.ai.mit.edu; Fri, 18 May 90 07:08:42 edt
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA18193; Fri, 18 May 90 02:51:41 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa08450;
18 May 90 2:19 EDT
Message-Id: <DIGEST.184.900518.021923.31@MC.LCS.MIT.EDU>
Date: 18 May 90 02:19:23 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #372
Scheme Digest #372 18 May 90 02:19:23 EDT
Today's Topics:
MacScheme application-builder question
----------------------------------------------------------------------
Message-ID: <40093@brunix.UUCP>
Date: 17 May 90 15:21:12 GMT
From: Mark Johnson <brunix!mj@uunet.uu.net>
To: scheme@mc.lcs.mit.edu
Subject: MacScheme application-builder question
I've found MaScheme+Toolsmith to be very convenient for developing
specialized one-off applications for the Mac (it has one big advantage
over the "other" lisp for the Mac - it's stand-alone applications will
fit on a floppy disk!). But I've run into a problem with an
application that imports text via the clip-board, massages it and
exports it back (this is a home-brewed equation numberer and referencer
for Word): the stand-alone application doesn't leave enough space in
the Mac Heap for me to copy in medium-to-large papers.
Is there any way to increase the size of the Mac heap in a stand-alone
MacScheme application? Increasing the application's size just increases
the size of the Scheme heap.
By the way, what's the current version of MacScheme+toolsmith. I have
a feeling I haven't been getting upgrade notices.
Thanks,
Mark Johnson
------------------------------
End of Scheme Digest
********************
∂18-May-90 2310 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #373
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 18 May 90 23:10:14 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA12751; Sat, 19 May 90 02:09:44 EDT
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Sat, 19 May 90 02:07:22 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa11248;
19 May 90 2:07 EDT
Message-Id: <DIGEST.184.900519.020432.36@MC.LCS.MIT.EDU>
Date: 19 May 90 02:04:32 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #373
Scheme Digest #373 19 May 90 02:04:32 EDT
Today's Topics:
Looking for a program
Another lisp for the MAC
----------------------------------------------------------------------
Message-ID: <10643@sdcc6.ucsd.edu>
Date: 18 May 90 22:18:00 GMT
From: David "OliverJones" Moore <sdcc6!sdcc7!cs64sel@ucsd.edu>
To: scheme@mc.lcs.mit.edu
Subject: Looking for a program
I am looking for a version of Scheme which runs upon the
Macintosh computer. Any and all pointers requested. If there is
some form of pd or shareware or other low cost release, that would
be great, but anything will do.
David Moore
--
David Moore (I don't know what I am saying, why should anyone else.)
E-Mail: dmoore@ucsd.edu dmoore@crash.cts.com
US-Mail: 13127 Sundance Ave San Diego, CA 92129
"God does not play dice." - A. Einstein "Yes, I do." - D. Moore
------------------------------
Message-ID: <9005190336.AA07272@mailhost.samsung.com>
Date: Fri, 18 May 90 20:40:28 EDT
From: gjc@mitech.com
Reply-To: gjc@mitech.com
To: scheme@lcs.mit.edu
Subject: Another lisp for the MAC
Jim O'Dell (jim@fpr.com) has ported good-old Franz Lisp
to the Mac. It can produce double-click applications, and its C "kernel"
was developed using LightSpeed C.
Myself, I never really like Franz Lisp, considering it to
be *derivative* (in the creative and qualitative sense).
But it is relatively small and has a native-code compiler, so it has
some capability for applications.
-gjc
------------------------------
End of Scheme Digest
********************
∂21-May-90 0030 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #374
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 May 90 00:29:51 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA01567; Mon, 21 May 90 03:28:00 EDT
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Mon, 21 May 90 03:25:40 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa10536;
21 May 90 3:18 EDT
Message-Id: <DIGEST.184.900521.024942.43@MC.LCS.MIT.EDU>
Date: 21 May 90 02:49:41 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #374
Scheme Digest #374 21 May 90 02:49:41 EDT
Today's Topics:
Linkage Editors Info.
elk 1.1 available by anonymous ftp on labrea.stanford.edu
----------------------------------------------------------------------
Message-ID: <1990May20.131746.7161@lth.se>
Date: 20 May 90 13:17:46 GMT
From: Mohd Hanafiah-Abdullah <eru!luth!sunic!lth.se!newsuser@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Linkage Editors Info.
Hello
Could anyone please provide me references regarding
design and implementation of "linkage editors" and
"loaders"?
Concerning the "linker", I am particularly interested
in supporting separate compilation facility for block
structured languages, both "untyped" (like Scheme),
and "heavily typed" (like Modula-2).
Please reply via e-mail to the following addresses:
x90mha@efd.lth.se
napi@rangkom.MY (in case I have left Sweden for
Malaysia)
Thanks in advance.
Mohd Hanafiah Abdullah
------------------------------
Message-ID: <HAM.90May18145524@Neon.Stanford.EDU>
Date: 18 May 90 21:55:24 GMT
From: "Peter R. Ham" <eos!shelby!neon!neon.Stanford.EDU!ham@AMES.ARC.NASA.GOV>
To: scheme@mc.lcs.mit.edu
Subject: elk 1.1 available by anonymous ftp on labrea.stanford.edu
On this machine in ~ftp/pub/elk-1.1.tar.Z is the latest elk
that I just received from Oliver Laumann. I haven't tested
it out yet. Anybody has the code to port it to a decstation?
Peter
--
Peter Ham PO Box 3430 (h)(415) 322-4390
MS Computer Science Student Stanford, CA ham@cs.stanford.edu
Stanford University 94309 (o)(415) 723-2067
------------------------------
End of Scheme Digest
********************
∂22-May-90 0001 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #375
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 May 90 00:00:59 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA20361; Tue, 22 May 90 02:59:08 EDT
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Tue, 22 May 90 02:56:50 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa15686;
22 May 90 2:52 EDT
Message-Id: <DIGEST.184.900522.023449.49@MC.LCS.MIT.EDU>
Date: 22 May 90 02:34:49 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #375
Scheme Digest #375 22 May 90 02:34:49 EDT
Today's Topics:
Elk 1.1 available by anonymous ftp on labrea.stanford.edu
LeLisp info request
Another lisp for the MAC
----------------------------------------------------------------------
Message-ID: <1339@tub.UUCP>
Date: 21 May 90 08:46:29 GMT
From: Oliver Laumann <mcsun!unido!tub!net@uunet.uu.net>
To: scheme@mc.lcs.mit.edu
Subject: Re: Elk 1.1 available by anonymous ftp on labrea.stanford.edu
In article <HAM.90May18145524@Neon.Stanford.EDU> ham@Neon.Stanford.EDU (Peter R. Ham) writes:
> On this machine in ~ftp/pub/elk-1.1.tar.Z is the latest elk
Thank you for making it available on your machine.
> Anybody has the code to port it to a decstation?
I'm porting it to a Sony NEWS 3860 (MIPS R3000 CPU) right now. Since
the DECStation has a MIPS CPU and, as far as I know, the same a.out
format than the Sony (ECOFF), it should run on the DECStation as well
(the MIPS stack.s and the ECOFF support have been contributed by
George Hartzell <hartzell@boulder.colorado.edu>).
--
Oliver Laumann net@TUB.BITNET net@tub.cs.tu-berlin.de net@tub.UUCP
------------------------------
Message-ID: <18084@well.sf.ca.us>
Date: 21 May 90 14:14:41 GMT
From: Jeffrey Jacobs <snorkelwacker!apple!well!jjacobs@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: LeLisp info request
LeLisp was a highly portable LISP developed at INRIA in France. It was
*not* Common LISP. It was available for a brief time from Expertelligence,
but they have stopped marketing it.
My understanding is that development of/in LeLisp has effectively ceased
and that the Europeans have accepted Common LISP...
Jeff Jacobs
ConsArt Systems Inc.
Manhattan Beach, CA 90266
(213)376-3802
------------------------------
Message-ID: <1990May22.023701.17596@eplrx7.uucp>
Date: 22 May 90 02:37:01 GMT
From: Walt Leipold <eplrx7!leipold@louie.udel.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: Another lisp for the MAC
In article <9005190336.AA07272@mailhost.samsung.com> gjc@mitech.com writes:
>Jim O'Dell (jim@fpr.com) has ported good-old Franz Lisp
>to the Mac. It can produce double-click applications, and its C "kernel"
>was developed using LightSpeed C.
If anybody's interested in a *real* simple Scheme, I've ported George
Carrette's C version of siod (Scheme In One Defun) to the Mac, both as
a standalone Think C program (only 36K, including the dialog box for
command-line args) and as an MPW tool (with file redirection and
piping). Someday I'm gonna add some graphics primitives and have a
cute little demo system. Write if you'd like source code...
--
"As long as you've lit one candle, Walt Leipold
you're allowed to curse the darkness." (leipolw%esvax@dupont.com)
--
--
The UUCP Mailer
------------------------------
End of Scheme Digest
********************
∂22-May-90 2325 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #376
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 May 90 23:25:35 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA04826; Wed, 23 May 90 02:20:03 EDT
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Wed, 23 May 90 02:17:44 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa09426;
23 May 90 2:19 EDT
Message-Id: <DIGEST.184.900523.021956.54@MC.LCS.MIT.EDU>
Date: 23 May 90 02:19:55 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #376
Scheme Digest #376 23 May 90 02:19:55 EDT
Today's Topics:
quasiquote
----------------------------------------------------------------------
Message-ID: <130@geocub.greco-prog.fr>
Date: 21 May 90 14:35:54 GMT
From: Pierre Casteran <mcsun!inria!geocub!casteran@uunet.uu.net>
To: scheme@mc.lcs.mit.edu
Subject: quasiquote
In the definition of pairs , there is a boolean field which allows or not the
set-car! or set-cdr! operations, for in instance you can't set-car! a list
created with the Quote special form.
Is there a set of rules for the Quasiquote special form that says where you can
or can't update some components?
A possible rule would be:
Translate the quasiquote form into a construction of quote, append, list,
cons ans so on, which maximizes the quoted part, and all but the quoted part
can be updated.
P. Casteran
------------------------------
End of Scheme Digest
********************
∂24-May-90 0014 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #377
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 24 May 90 00:14:08 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA23685; Thu, 24 May 90 03:12:54 EDT
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Thu, 24 May 90 03:10:34 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa13776;
24 May 90 3:09 EDT
Message-Id: <DIGEST.184.900524.030514.61@MC.LCS.MIT.EDU>
Date: 24 May 90 03:05:13 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #377
Scheme Digest #377 24 May 90 03:05:13 EDT
Today's Topics:
Looking for LISP interpreter for transputer
LeLisp info request: Le-Lisp is alive and well (4 messages)
quasiquote
Seeking latest Xscheme sources
LeLisp info request
----------------------------------------------------------------------
Message-ID: <7903@latcs1.oz.au>
Date: 23 May 90 08:57:58 GMT
From: Ajeet Parhar <snorkelwacker!usc!cs.utexas.edu!samsung!munnari.oz.au!ditmela!latcs1!parhar@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Looking for LISP interpreter for transputer
The subject says most of it. I'd be greatful for any information on
existing LISP interpreters (any dialect) that run on transputer
based systems.
- Ajeet Parhar.
Department of Computer Science
& Computer Engineering,
La Trobe University, ACSnet: parhar@latcs1.oz
Bundoora, CSnet: parhar@latcs1.oz
Victoria, 3083, ARPA: parhar%latcs1.oz.au@uunet.uu.net
Australia UUCP: ...!uunet!munnari!latcs1.oz.au!parhar
------------------------------
Message-ID: <8082@ilog.UUCP>
Date: 23 May 90 10:41:41 GMT
From: Joe Dubin <eru!luth!sunic!mcsun!inria!ilog!dubin@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: LeLisp info request: Le-Lisp is alive and well
In article <18084@well.sf.ca.us> jjacobs@well.sf.ca.us (Jeffrey Jacobs) writes:
From: jjacobs@well.sf.ca.us (Jeffrey Jacobs)
Newsgroups: comp.lang.scheme,comp.lang.lisp
Date: 21 May 90 14:14:41 GMT
References: <1990May2.021557.24873@Neon.Stanford.EDU>
Xref: ilog comp.lang.scheme:774 comp.lang.lisp:2149
LeLisp was a highly portable LISP developed at INRIA in France. It was
*not* Common LISP. It was available for a brief time from Expertelligence,
but they have stopped marketing it.
My understanding is that development of/in LeLisp has effectively ceased
and that the Europeans have accepted Common LISP...
Au contraire!
Le-Lisp was developed in 1980 by a team led by Jerome Chailloux at
INRIA, the French national computer science research laboratory. It
was developed as a direct result of the need for a small, portable,
efficient language for a VLSI design system.
Today Le-Lisp is installed at over 2000 customer sites in Europe,
Asia, and North America, and runs on most major computer systems
including Sun 3 and 4, Mac II, Apollo, Decstation, Vax, Sony,
Hewlett-Packard, Bull, PS/2, and 386. It is currently marketed by
several companies throughout Europe, including ILOG, Bull, and the
Sema Group. Its technical evolution is assured by ILOG and INRIA.
Many commercial products have been built on top of Le-Lisp (references
on request).
Le-Lisp is the de facto Lisp standard in France, and is quickly
becoming the de facto European standard. Le-Lisp version 16 is a
candidate for the ISO international Lisp standard along with
CommonLisp and EuLisp.
I sent a more detailed mail message to Mr. Rivin in reponse to his
original query. If anyone else would like more information on
Le-Lisp, please send me mail.
Joe Dubin dubin@ilog.fr
ILOG S.A.
2, avenue Gallieni
BP 85
94253 GENTILLY CEDEX
FRANCE
Telephone (33+ 1) 46.63.66.66
Fax (33+ 1) 46.63.15.82
------------------------------
Message-ID: <9005231704.AA10976@life.ai.mit.edu>
Date: Wed, 23 May 90 13:04:27 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
To: mcsun!inria!geocub!casteran@uunet.uu.net
CC: scheme@mc.lcs.mit.edu
Subject: quasiquote
Date: 21 May 90 14:35:54 GMT
From: Pierre Casteran <mcsun!inria!geocub!casteran@uunet.uu.net>
In the definition of pairs , there is a boolean field which allows or not the
set-car! or set-cdr! operations, for in instance you can't set-car! a list
created with the Quote special form.
Is there a set of rules for the Quasiquote special form that says where you can
or can't update some components?
During the last meeting of the Scheme standard working group, it was
proposed that all parts of lists generated by a quasiquote expression
be required to be mutable. This proposal was rejected, and in fact
the editors of the standard took this one step further and
deliberately removed some text implying that the result was immutable
in certain conditions. At present there are no mutability
requirements whatsoever, meaning that conforming programs must treat
the result as immutable.
This is perhaps unfortunate, but we felt that any rules we would come
up with would be ad hoc, and therefore undesirable; we also felt it
undesirable to make such a change this late in the standardization
process. This decision could be overcome by a well-motivated set of
rules or by evidence that such rules would be very useful -- but in
either case the argument would have to be fairly persuasive to cause a
change in this version of the standard.
------------------------------
Message-ID: <2924@ohm.sw.mcc.com>
Date: 23 May 90 18:03:56 GMT
From: "David Z. Creemer" <bu.edu!rpi!zaphod.mps.ohio-state.edu!samsung!cs.utexas.edu!milano!ohm!creemer@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Seeking latest Xscheme sources
Greetings,
I am looking for the latest release of David Betz's Xscheme.
Any help would be appreciated.
Thanks alot,
-- David
David Creemer | MCC Software Technology Program | creemer@mcc.com
512 338-3403 | 9390 Research, Kaleido II Bldg., Austin, Texas 78759
------------------------------
Message-ID: <1990May23.193813.14195@cs.rochester.edu>
Date: 23 May 90 19:38:13 GMT
From: Massimo Poesio <rochester!poesio@rutgers.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: LeLisp info request: Le-Lisp is alive and well
Hey, I don't know about France, but saying that LeLisp
is quickly becoming the de facto standard in Europe
is pushing it a bit too far. I have been working in Italy and
Germany, and, while sure enough people knew LeLisp existed
(and in one company where I worked they even had an interpreter)
I never heard of anybody actually using it.
Massimo Poesio
University of Rochester
Computer Science Department
Rochester, NY 14627
email: poesio@cs.rochester.edu
phone: (716) 275-5605
------------------------------
Message-ID: <2533@skye.ed.ac.uk>
Date: 23 May 90 21:15:33 GMT
From: Jeff Dalton <mcsun!ukc!edcastle!aiai!jeff@uunet.uu.net>
To: scheme@mc.lcs.mit.edu
Subject: Re: LeLisp info request
In article <18084@well.sf.ca.us> jjacobs@well.sf.ca.us (Jeffrey Jacobs) writes:
>My understanding is that development of/in LeLisp has effectively ceased
>and that the Europeans have accepted Common LISP...
Le_Lisp is alive and well and living in France. Development continues.
Some Europeans have accepted Common Lisp, others have not.
------------------------------
Message-ID: <2534@skye.ed.ac.uk>
Date: 23 May 90 21:22:23 GMT
From: Jeff Dalton <mcsun!ukc!edcastle!aiai!jeff@uunet.uu.net>
To: scheme@mc.lcs.mit.edu
Subject: Re: LeLisp info request: Le-Lisp is alive and well
In article <8082@ilog.UUCP> dubin@ilog.UUCP (Joe Dubin) writes:
>Le-Lisp is the de facto Lisp standard in France, and is quickly
>becoming the de facto European standard.
I think it is going a bit far to say it is becoming a de facto
European standard. It is very strong in France, not so noticable
elsewhere.
>Le-Lisp version 16 is a candidate for the ISO international Lisp
>standard along with CommonLisp and EuLisp.
The current ISO plan seems to be to develop a "kernel" that is the
interestion (in some sense) of Common Lisp, Le_Lisp, and EuLisp.
Those three were chosen because they were the drafts submitted
under an earlier work plan. What will finally come of all this
remains to be seen.
-- Jeff
------------------------------
Message-ID: <12387@unix.SRI.COM>
Date: 24 May 90 02:31:27 GMT
From: Francois Felix INGRAND <unix!AI.SRI.COM@rutgers.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: LeLisp info request: Le-Lisp is alive and well
In article <2534@skye.ed.ac.uk>, jeff@aiai (Jeff Dalton) writes:
>In article <8082@ilog.UUCP> dubin@ilog.UUCP (Joe Dubin) writes:
>>Le-Lisp is the de facto Lisp standard in France, and is quickly
>>becoming the de facto European standard.
>
>I think it is going a bit far to say it is becoming a de facto
>European standard. It is very strong in France, not so noticable
>elsewhere.
Well, even in France, not everybody is using Lelisp. It is still
unclear to me what are the advantage of Lelisp over Common Lisp. As
far as I remember, it is smaller, and highly portable because of an
intermediate code. I also remember that for a long time, it was the
only decent lisp available on small platform (Mac, PC, etc), but I
also remember a "clumsy" syntax in old release (why use "de" when
everybody is already using "defun"...). Can somebody clarify what are
the good reasons why Lelisp is around (advantages over Common Lisp,
etc).
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Francois Felix INGRAND SRI International, AIC
felix@AI.SRI.COM 333, Ravenswood Avenue
felix%AI.SRI.COM@UUNET.UU.NET MENLO PARK, CA 94025, USA
"Pourquoi tant de haine..." (Edika) "Read my Lisp... No new syntax" (nil)
------------------------------
End of Scheme Digest
********************
∂25-May-90 0005 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #378
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 25 May 90 00:05:41 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA11448; Fri, 25 May 90 03:03:53 EDT
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Fri, 25 May 90 03:01:24 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa28677;
25 May 90 2:58 EDT
Message-Id: <DIGEST.184.900525.025025.67@MC.LCS.MIT.EDU>
Date: 25 May 90 02:50:25 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #378
Scheme Digest #378 25 May 90 02:50:25 EDT
Today's Topics:
LeLisp info request: Le-Lisp is alive and well (2 messages)
support for Xt, etc?
----------------------------------------------------------------------
Message-ID: <18139@well.sf.ca.us>
Date: 24 May 90 14:45:32 GMT
From: Jeffrey Jacobs <bu.edu!rpi!zaphod.mps.ohio-state.edu!mips!apple!well!jjacobs@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: LeLisp info request: Le-Lisp is alive and well
I'm *very* glad to hear that Le_Lisp is indeed still alive and well in
Europe. Its too bad that it didn't catch on better in the U.S.
Jeffrey M. Jacobs
------------------------------
Message-ID: <136167@sun.Eng.Sun.COM>
Date: 24 May 90 17:45:35 GMT
From: "Vladimir G. Ivanovic" <prosper@sun.com>
To: scheme@mc.lcs.mit.edu
Subject: Re: LeLisp info request: Le-Lisp is alive and well
In article <18139@well.sf.ca.us>, jjacobs@well (Jeffrey Jacobs) writes:
>
>I'm *very* glad to hear that Le_Lisp is indeed still alive and well in
>Europe. Its too bad that it didn't catch on better in the U.S.
>
>Jeffrey M. Jacobs
Would you care to elaborate? What features are sufficiently better than, say,
Scheme or Common Lisp to justify having YAVL (Yet Another Version of Lisp),
another standard, another learning curve?
--
Vladimir G. Ivanovic vladimir@sun.com
M/S 12-33 vladimir@prosper.ebb.eng.sun.com
Sun Microsystems, Inc. vivanovic@sun.com
------------------------------
Message-ID: <9005250155.AA04836@modesty.stanford.edu>
Date: Thu, 24 May 90 18:55:04 PDT
From: Ramani Pichumani <ramani@patience.stanford.edu>
To: scheme@ai.mit.edu
Subject: support for Xt, etc?
I have been thinking about writing a large X windows based application
in MIT Scheme. After taking a look at the scheme distribution from
MIT, I'm left wondering about how much serious X application
development has been done with Scheme. I am especially interested in
being able to use Xt with Scheme. Coming from a CommonLisp/CLX
background, I'm rather clueless as to how to attempt such a project in
Scheme without having to build up the necessary tools from scratch.
Is there a publicly available set of runtime packages to support high
level X applications in MIT Scheme? Please reply to me directly since
I am not yet on the scheme mailing list.
Thanks in advance,
-------
Ramani Pichumani Tel: (415) 723-2902 or 723-2437
Department of Computer Science Fax: (415) 725-7411
Margaret Jacks Hall, Room 308 email: ramani@patience.stanford.edu
Stanford, CA 94305 USA uunet!patience.stanford.edu!ramani
------------------------------
End of Scheme Digest
********************
∂26-May-90 0014 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #379
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 26 May 90 00:14:36 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA25824; Sat, 26 May 90 03:14:27 EDT
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Sat, 26 May 90 03:12:04 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa11970;
26 May 90 3:13 EDT
Message-Id: <DIGEST.184.900526.031021.2@MC.LCS.MIT.EDU>
Date: 26 May 90 03:10:20 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #379
Scheme Digest #379 26 May 90 03:10:20 EDT
Today's Topics:
LeLisp info request: Le-Lisp is alive and well
----------------------------------------------------------------------
Message-ID: <2576@skye.ed.ac.uk>
Date: 25 May 90 18:23:29 GMT
From: Jeff Dalton <mcsun!ukc!edcastle!aiai!jeff@uunet.uu.net>
To: scheme@mc.lcs.mit.edu
Subject: Re: LeLisp info request: Le-Lisp is alive and well
In article <136167@sun.Eng.Sun.COM> vladimir@prosper (Vladimir G. Ivanovic) writes:
>In article <18139@well.sf.ca.us>, jjacobs@well (Jeffrey Jacobs) writes:
>>I'm *very* glad to hear that Le_Lisp is indeed still alive and well in
>>Europe. Its too bad that it didn't catch on better in the U.S.
>Would you care to elaborate? What features are sufficiently better than, say,
>Scheme or Common Lisp to justify having YAVL (Yet Another Version of Lisp),
>another standard, another learning curve?
Well, Jeff Jacobs is well-known as a critic of Common Lisp, so I'm
sure he'll be able to provide some reasons.
As for Scheme, it still lacks such things as macros, modules,
condition handling, and even the ability to define new (disjoint)
types; many people would like to use Lisps that have such features
rather than wait for Scheme to do it right.
This is not to say Scheme is bad. I'm glad Scheme is being developed
in the way it is. However, I also think it's a good idea to have some
variety in the Lisp world so that we don't get stuck in too few ways
of doing things.
Jeff Dalton, JANET: J.Dalton@uk.ac.ed
AI Applications Institute, ARPA: J.Dalton%uk.ac.ed@nsfnet-relay.ac.uk
Edinburgh University. UUCP: ...!ukc!ed.ac.uk!J.Dalton
------------------------------
End of Scheme Digest
********************
∂27-May-90 0009 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #380
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 27 May 90 00:09:26 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA03395; Sun, 27 May 90 03:08:36 EDT
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Sun, 27 May 90 03:06:09 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa08748;
27 May 90 3:04 EDT
Message-Id: <DIGEST.184.900527.025522.6@MC.LCS.MIT.EDU>
Date: 27 May 90 02:55:21 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #380
Scheme Digest #380 27 May 90 02:55:21 EDT
Today's Topics:
(input-port? (close-input-port (open-input-file "/dev/null"))) ??
LeLisp info request: Le-Lisp is alive and well
----------------------------------------------------------------------
Message-ID: <1892@majestix.ida.liu.se>
Date: 26 May 90 14:52:34 GMT
From: Mikael Pettersson <zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!liuida!mikpe@think.com>
To: scheme@mc.lcs.mit.edu
Subject: (input-port? (close-input-port (open-input-file "/dev/null"))) ??
From reading the R4RS (actually, the R3.99RS and the draft IEEE P1178/D4),
section 6.10.1. Ports, one can obtain the following definitions:
(A) [at the top]
"..an input port is a Scheme object that can deliver characters
upon command.."
(B) [just below (close-input-port port)]
"Closes the file associated with port, rendering the port
incapable of delivering .. characters."
(C) [next sentence below (close-input-port port)]
"These routines have no effect if the file has already been closed."
Now, from (A) and (B) it would seem that once a port has been closed,
it ceases to be a port. On the other hand, (C) seems to imply the
opposite.
Maybe I'm nit-picking (probably :-)), but we don't want accidental
undefinedness in the language definition, do we? [the report is
otherwise pretty careful in describing what is and what is not
undefined behavior]
On a related issue: it's explicitly stated that "It is an error to
read from a closed port.", but no such statement is made about trying
to _write_ to a closed port.. what's the deal here?
/Mike
--
Mikael Pettersson, Dept of Comp & Info Sci, University of Linkoping, Sweden
email: mpe@ida.liu.se or ...!{mcsun,munnari,uunet,unido,...}!sunic!liuida!mpe
------------------------------
Message-ID: <136285@sun.Eng.Sun.COM>
Date: 26 May 90 19:58:49 GMT
From: "Vladimir G. Ivanovic" <prosper@sun.com>
To: scheme@mc.lcs.mit.edu
Subject: Re: LeLisp info request: Le-Lisp is alive and well
In article <2576@skye.ed.ac.uk>, jeff@aiai (Jeff Dalton) writes:
>
>As for Scheme, it still lacks such things ....
>
My question is still unanswered. I'm NOT arguing the merits or flaws of
Scheme or Common Lisp. It appears you are, but I'm not. I wanted to know why
we need still another version of Lisp.
The original poster made an assertion that it was a good thing that Le-Lisp
was developed. I am curious why that assertion was made.
Are there some features of Le-Lisp that are not present in Scheme or Common
Lisp that are "good" to have? What are those features and why are they good?
Does Le-Lisp correct some mistakes that other versions of Lisp make? What are
those mistakes? Etc., etc.
It seems to me these are entirely reasonable questions to ask. I'm not wedded
to either Scheme or Common Lisp. And I'm not anit-Scheme ro Common Lisp. If
Le-Lisp is better, I'd like to know about it. If its raison-etre is to
provide tenure to some professor and employment to a generation of graduate
student, I'd like to know that also.
I'm seeking information, and I was under the impression that that was what
newsgroups were all about. Correct me if I'm wrong.
Cheers,
-- Vladimir
--
Vladimir G. Ivanovic vladimir@sun.com
M/S 12-33 vladimir@prosper.ebb.eng.sun.com
Sun Microsystems, Inc. vivanovic@sun.com
------------------------------
End of Scheme Digest
********************
∂28-May-90 0004 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #381
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 28 May 90 00:04:21 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA10444; Mon, 28 May 90 02:50:56 EDT
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Mon, 28 May 90 02:48:40 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa03579;
28 May 90 2:44 EDT
Message-Id: <DIGEST.184.900528.024022.9@MC.LCS.MIT.EDU>
Date: 28 May 90 02:40:21 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #381
Scheme Digest #381 28 May 90 02:40:21 EDT
Today's Topics:
LeLisp info request: Le-Lisp is alive and well
----------------------------------------------------------------------
Message-ID: <2591@skye.ed.ac.uk>
Date: 27 May 90 17:53:44 GMT
From: Jeff Dalton <mcsun!ukc!edcastle!aiai!jeff@uunet.uu.net>
To: scheme@mc.lcs.mit.edu
Subject: Re: LeLisp info request: Le-Lisp is alive and well
In article <136285@sun.Eng.Sun.COM> vladimir@prosper (Vladimir G. Ivanovic) writes:
>My question is still unanswered. I'm NOT arguing the merits or flaws of
>Scheme or Common Lisp. It appears you are, but I'm not.
All I did was provide a list of features that are not yet in (standard
or R*RS) Scheme.
>Are there some features of Le-Lisp that are not present in Scheme or Common
>Lisp that are "good" to have?
See my previous message. Common Lisp does have such things, but some
people prefer the form they take in Le_Lisp.
Since this newsgroup is forwarded to the Scheme mailing list, and
since some people on that list don't like to receive discussions of
this sort, I think we should persue this via mail or in comp.lang.
lisp (where I have directed followups).
-- Jeff
------------------------------
End of Scheme Digest
********************
∂29-May-90 0055 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #382
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 29 May 90 00:54:53 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA20728; Tue, 29 May 90 03:53:01 EDT
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Tue, 29 May 90 03:50:16 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa06478;
29 May 90 3:48 EDT
Message-Id: <DIGEST.184.900529.034022.13@MC.LCS.MIT.EDU>
Date: 29 May 90 03:40:21 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #382
Scheme Digest #382 29 May 90 03:40:21 EDT
Today's Topics:
readings in scheme (was Re: LeLisp ...)
----------------------------------------------------------------------
Message-ID: <11257@yunexus.UUCP>
Date: 29 May 90 03:38:31 GMT
From: Ozan Yigit <attcan!utgpu!news-server.csri.toronto.edu!helios.physics.utoronto.ca!ists!yunexus!oz@uunet.uu.net>
To: scheme@mc.lcs.mit.edu
Subject: readings in scheme (was Re: LeLisp ...)
In article <2576@skye.ed.ac.uk> jeff@aiai.UUCP (Jeff Dalton) writes:
[I assume this is about the language "definition" as in R↑nRS]
>As for Scheme, it still lacks such things as macros, modules,
>condition handling, and even the ability to define new (disjoint)
>types; many people would like to use Lisps that have such features
>rather than wait for Scheme to do it right.
If anything is worth doing right, it is also worth waiting for.
Scheme people do not just add features to the language for the sake of it.
They experiment with these things, and try to carefully select only those
things that make sense and capture the required functionality without
being gratuitous or redundant. It takes time to know what *not* to add.
This seems to be a good time to re-post the scheme bibliography (bib/refer
version). As usual, I would welcome any additions, comments, etc. you may
have. Updates to this biblio regularly appear in the Lisp Pointers.
enjoy... oz
------------------
%A John Reynolds
%T Definitional Interpreters for Higher Order Programming Languages
%J ACM Conference Proceedings
%P 717-740
%I ACM
%D 1972
%A Gerald Jay Sussman
%A Guy Lewis Steele Jr.
%T Scheme: an Interpreter for Extended Lambda Calculus
%R MIT Artificial Intelligence Memo 349
%C Cambridge, Mass.
%D December 1975
%A Guy Lewis Steele Jr.
%A Gerald Jay Sussman
%T Lambda, the Ultimate Imperative
%R MIT Artificial Intelligence Memo 353
%C Cambridge, Mass.
%D March 1976
%K imperative
%A Guy Lewis Steele Jr.
%T Lambda, the Ultimate Declarative
%R MIT Artificial Intelligence Memo 379
%C Cambridge, Mass.
%D November 1976
%K declarative
%A Guy Lewis Steele Jr.
%T Debunking the ``Expensive Procedure Call'' Myth, or Procedure Call
Implementations Considered Harmful, or LAMBDA, the Ultimate GOTO
%J ACM Conference Proceedings
%P 153-162
%I ACM
%D 1977
%K ultimate
%A Guy Lewis Steele Jr.
%T Macaroni is Better than Spaghetti
%J Proceedings of the Symposium on Artificial Intelligence and
Programming Languages
%P 60-66
%O Special joint issue of SIGPLAN Notices 12(8) and SIGART Newsletter 64
%D August 1977
%K macaroni
%A Mitchell Wand
%T Continuation-Based Program Transformation Strategies
%J Journal of the ACM
%V 27
%N 1
%P 174-180
%D 1978
%A Mitchell Wand
%A Daniel P. Friedman
%T Compiling lambda expressions using continuations and
factorizations
%J Journal of Computer Languages
%V 3
%P 241-263
%D 1978
%A Guy Lewis Steele Jr.
%A Gerald Jay Sussman
%T The Revised Report on Scheme, a Dialect of Lisp
%R MIT Artificial Intelligence Memo 452
%C Cambridge, Mass.
%D January 1978
%K r-report
%A Guy Lewis Steele Jr.
%T Rabbit: a Compiler for Scheme
%R MIT Artificial Intelligence Laboratory Technical Report 474
%C Cambridge, Mass.
%D May 1978
%K rabbit
%A Guy Lewis Steele Jr.
%A Gerald Jay Sussman
%T The Art of the Interpreter, or the Modularity Complex
(parts zero, one, and two)
%R MIT Artificial Intelligence Memo 453
%C Cambridge, Mass.
%D May 1978
%K modularity
%A Uwe F. Pleban
%T The Standard Semantics of a Subset of SCHEME, a Dialect of LISP
%R Computer Science Technical Report TR-79-3
%I University of Kansas
%C Lawrence, Kansas
%D July 1979
%A Guy Lewis Steele Jr.
%T Compiler Optimization Based on Viewing LAMBDA as RENAME + GOTO
%B AI: An MIT Perspective
%E Patrick Henry Winston
%E Richard Henry Brown
%I MIT Press
%C Cambridge, Mass.
%D 1980
%K rename+goto
%A Guy Lewis Steele Jr.
%A Gerald Jay Sussman
%T The Dream of a Lifetime: a Lazy Variable Extent Mechanism
%J Conference Record of the 1980 Lisp Conference
%P 163-172
%I The Lisp Conference
%D 1980
%K lazy
%A Drew McDermott
%T An Efficient Environment Allocation Scheme in an Interpreter
for a Lexically-Scoped Lisp
%J Conference Record of the 1980 Lisp Conference
%P 154-162
%I The Lisp Conference, P.O. Box 487, Redwood Estates CA.
%D 1980
%O Proceedings reprinted by ACM
%A Steven S. Muchnick
%A Uwe F. Pleban
%T A Semantic Comparison of Lisp and Scheme
%J Conference Record of the 1980 Lisp Conference
%P 56-65
%I The Lisp Conference, P.O. Box 487, Redwood Estates CA.
%D 1980
%A Uwe F. Pleban
%T A Denotational Approach to Flow Analysis and Optimization of
SCHEME, A Dialect of LISP
%R Ph.D. Dissertation
%I University of Kansas
%C Lawrence, Kansas
%D 1980
%A Mitchell Wand
%T Continuation-Based Multiprocessing
%J Conference Record of the 1980 Lisp Conference
%P 19-28
%I The Lisp Conference
%D 1980
%A Mitchell Wand
%T SCHEME Version 3.1 Reference Manual
%R Computer Science Technical Report 93
%I Indiana University
%C Bloomington, Indiana
%D June 1980
%K scheme3.1
%A Guy Lewis Steele Jr.
%A Gerald Jay Sussman
%T Design of a Lisp-based Processor
%J CACM
%V 23
%N 11
%P 628-645
%D November 1980
%A Rex A. Dwyer
%A R. Kent Dybvig
%T A SCHEME for Distributed Processes
%R Computer Science Department Technical Report #107
%I Indiana University
%C Bloomington, Indiana
%D April 1981
%A Gerald Jay Sussman
%A Jack Holloway
%A Guy Lewis Steele Jr.
%A Alan Bell
%T Scheme-79 - Lisp on a Chip
%J IEEE Computer
%V 14
%N 7
%P 10-21
%D July 1981
%I IEEE
%K scheme79
%A John Batali
%A Edmund Goodhue
%A Chris Hanson
%A Howie Shrobe
%A Richard M. Stallman
%A Gerald Jay Sussman
%T The Scheme-81 Architecture - System and Chip
%J Proceedings, Conference on Advanced Research in VLSI
%P 69-77
%E Paul Penfield, Jr.
%C Artech House, Dedham MA.
%D 1982
%K scheme81
%A Jonathan A. Rees
%A Norman I. Adams
%T T: A Dialect of Lisp or, LAMBDA: The Ultimate Software Tool
%J Conference Record of the 1982 ACM Symposium on Lisp and
Functional Programming
%P 114-122
%D 1982
%K T
%A Gerald Jay Sussman
%T LISP, Programming and Implementation
%B Functional Programming and its Applications
%E Darlington, Henderson, Turner
%I Cambridge University Press
%C London
%D 1982
%A R. Kent Dybvig
%T C-Scheme
%R Computer Science Department Technical Report #149 (MS Thesis)
%I Indiana University
%C Bloomington, Indiana
%D 1983
%A Pee Hong Chen
%A W.Y. Chi
%A E.M. Ost
%A L.D. Sabbagh
%A G. Springer
%T Scheme Graphics Reference Manual
%R Computer Science Technical Report No. 145
%I Indiana University
%C Bloomington, Indiana
%D August 1983
%A Pee Hong Chen
%A Daniel P. Friedman
%T Prototyping data flow by translation into Scheme
%R Computer Science Technical Report #147
%I Indiana University
%C Bloomington, Indiana
%D August 1983
%A Carol Fessenden
%A William Clinger
%A Daniel P. Friedman
%A Christopher T. Haynes
%T Scheme 311 version 4 Reference Manual
%R Computer Science Technical Report 137
%I Indiana University
%C Bloomington, Indiana
%D February 1983
%O Superceded by Computer Science Technical Report 153, 1985
%K scheme311
%A William Clinger
%T The Scheme 311 compiler: An Exercise in Denotational Semantics
%J Conference Record of the 1984 ACM Symposium on Lisp and
Functional Programming
%P 356-364
%D 1984
%K compile311
%A Daniel P. Friedman
%A Christopher T. Haynes
%A Eugene E. Kohlbecker
%T Programming with Continuations
%B Program Transformation and Programming Environments
%P 263-274
%E P. Pepper
%I Springer-Verlag
%D 1984
%A Christopher T. Haynes
%A Daniel P. Friedman
%T Engines Build Process Abstractions
%J Conference Record of the 1984 ACM Symposium on Lisp and
Functional Programming
%C Austin, TX.
%P 18-24
%D 1984
%A Christopher T. Haynes
%A Daniel P. Friedman
%A Mitchell Wand
%T Continuations and Coroutines
%J Conference Record of the 1984 ACM Symposium on Lisp and
Functional Programming
%C Austin, TX.
%P 293-298
%D 1984
%A Daniel P. Friedman
%A Mitchell Wand
%T Reification: reflection without metaphysics
%J Conference Record of the 1984 ACM Symposium on LISP and Functional
Programming
%C Austin, TX.
%P 348-355
%D August 1984
%A Jonathan A. Rees
%A Norman I. Adams
%A James R. Meehan
%T The T manual, fourth edition
%I Yale University Computer Science Department
%D January 1984
%A Guillermo J. Rozas
%T Liar, an Algol-like Compiler for Scheme
%I S. B. Thesis, MIT Department of Electrical Engineering and Computer
Science
%D January 1984
%K liar
%A Richard Schooler
%A James W. Stamos
%T Proposal For a Small Scheme Implementation
%R MIT Lab for Computer Science Memo TM-267
%C Cambridge, Mass.
%D October 1984
%T MIT Scheme Manual, Seventh Edition
%I Department of Electrical Engineering and Computer Science, MIT
%C Cambridge, Mass.
%D September 1984
%K mitscheme
%T MacScheme Reference Manual
%I Semantic Microsystems
%C Sausalito, California
%D 1985
%K macscheme
%A Harold Abelson
%A Gerald Jay Sussman
%A Julie Sussman
%T Structure and Interpretation of Computer Programs
%I MIT Press
%C Cambridge, Mass.
%D 1985
%K siocp
%A William Clinger
%A Daniel P. Friedman
%A Mitchell Wand
%T A Scheme for a Higher-Level Semantic Algebra
%B Algebraic Methods in Semantics
%E J. Reynolds, M. Nivat
%P 237-250
%I Cambridge University Press
%C London
%D 1985
%A Amitabh Srivastava
%A Don Oxley
%A Aditya Srivastava
%T An (other) Integration of Logic and Functional Programming
%J Proceedings of the Symposium on Logic Programming
%P 254-260
%I IEEE
%D 1985
%E William Clinger
%T The Revised Revised Report on Scheme, or An Uncommon Lisp
%R MIT Artificial Intelligence Memo 848
%C Cambridge, Mass.
%O Also published as Computer Science Department Technical Report 174,
Indiana University, June 1985
%D August 1985
%K rrrs
%A Daniel P. Friedman
%A Christopher T. Haynes
%T Constraining Control
%J Proceedings of the Twelfth Annual Symposium on Principles of
Programming Languages
%C New Orleans, LA.
%P 245-254
%I ACM
%D January 1985
%A Daniel P. Friedman
%A Christopher T. Haynes
%A Eugene E. Kohlbecker
%A Mitchell Wand
%T Scheme 84 Interim Reference Manual
%R Computer Science Technical Report 153
%I Indiana University
%C Bloomington, Indiana
%D January 1985
%K scheme84
%A Peehong Chen
%A L. David Sabbagh
%T Scheme as an Interactive Graphics Programming Environment
%R Computer Science Technical Report No. 166
%I Indiana University
%C Bloomington, Indiana
%D March 1985
%A R. Kent Dybvig
%A Bruce T. Smith
%T Chez Scheme Reference Manual Version 1.0
%I Cadence Research Systems
%C Bloomington, Indiana
%D May 1985
%T TI Scheme Language Reference Manual
%I Texas Instruments, Inc.
%O Preliminary version 1.0
%D November 1985
%A Michael A. Eisenberg
%T Bochser: An Integrated Scheme Programming System
%R MIT Computer Science Technical Report 349
%C Cambridge, Mass.
%D October 1985
%K bochser
%T Transliterating Prolog into Scheme
%A Matthias Felleisen
%R Computer Science Technical Report #182
%I Indiana University
%C Bloomington, Indiana
%D October 1985
%A David H. Bartley
%A John C. Jensen
%T The Implementation of PC Scheme
%J Proceedings of the 1986 ACM Conference on Lisp
and Functional Programming
%P 86-93
%D 1986
%K pcscheme
%A R. Kent Dybvig
%A Daniel P. Friedman
%A Christopher T. Haynes
%T Expansion-Passing style: Beyond Conventional Macros
%J Conference Record of the 1986 ACM Conference on Lisp and
Functional Programming
%P 143-150
%D 1986
%A Marc Feeley
%A Guy LaPalme
%T Closure Generation based on viewing LAMBDA as EPSILON plus COMPILE
%O Submitted for Publication
%D 1986
%A Matthias Felleisen
%A Daniel P. Friedman
%T A Closer Look At Export and Import Statements
%J Journal of Computer Languages
%V 11
%N 1
%P 29-37
%I Pergamon Press
%D 1986
%A Daniel P. Friedman
%A Matthias Felleisen
%T The Little LISPer: Second Edition
%I Science Research Associates, Inc.
%C Palo Alto, California
%D 1986
%A Christopher T. Haynes
%A Daniel P. Friedman
%A Mitchell Wand
%T Obtaining Coroutines With Continuations
%J Journal of Computer Languages
%V 11
%N 3/4
%P 143-153
%I Pergamon Press
%D 1986
%A Mitchell Wand
%T From Interpreter to Compiler: A Representational Derivation
%B Programs as Data Objects
%I Springer-Verlag Lecture Notes
%D 1986
%A Mitchell Wand
%T Finding the Source of Type Errors
%J Conference Record of the Thirteenth Annual Symposium on
Principles of Programming Languages
%P 38-43
%I ACM
%C St. Peterburg, Fla.
%D 1986
%A Matthias Felleisen
%A Daniel P. Friedman
%T Control operators, the SECD-machine, and the lambda-calculus
%J 3rd Working Conference on the Formal Description of
Programming Concepts
%C Ebberup, Denmark
%P 193-219
%D August 1986
%A Eugene E. Kohlbecker
%T Syntactic Extensions in the Programming Language Lisp
%R Computer Science Technical Report #199 (Ph.D. Dissertation)
%I Indiana University
%C Bloomington, Indiana
%D August 1986
%A Eugene E. Kohlbecker
%A Daniel P. Friedman
%A Matthias Felleisen
%A Bruce Duba
%T Hygienic macro expansion
%J Symposium on LISP and Functional Programming
%P 151-161
%D August 1986
%O To appear in Lisp and Symbolic Computation
%K hygienic
%A Mitchell Wand
%T The mystery of the tower revealed: a non-reflective
description of the reflective tower
%J Proceedings of the 1986 ACM Symposium on LISP and Functional Programming
%P 298-307
%D August 1986
%K tower
%E Jonathan A. Rees
%E William Clinger
%T Revised↑3 Report on the Algorithmic Language Scheme
%J ACM Sigplan Notices
%V 21
%N 12
%D December 1986
%K rrrrs
%A Christopher T. Haynes
%T Logic Continuations
%J Proceedings of the Third International Conference on
Logic Programming
%P 671-685
%I Springer-Verlag
%D July 1986
%A Matthias Felleisen
%A Daniel P. Friedman
%A Eugene E. Kohlbecker
%A Bruce Duba
%T Reasoning with Continuations
%J Proceedings of the Symposium on Logic in Computer Science
%P 131-141
%I IEEE Computer Society Press
%C Washington DC
%D June 1986
%A David Kranz
%A Richard Kelsey
%A Jonathan A. Rees
%A Paul Hudak
%A James Philbin
%A Norman I. Adams
%T Orbit: An Optimizing Compiler for Scheme
%J Proceedings of the SIGPLAN '86 Symposium on Compiler
Construction
%P 219-233
%I ACM
%O Published as SIGPLAN Notices 21(7), July 1986
%D June 1986
%K orbit
%A Marc Feeley
%T Deux Approches a' L'implantation du Language Scheme
%I M.Sc. Thesis, De'partement d'Informatique et de Recherche
Ope'rationelle, University of Montreal
%D May 1986
%A Kevin J. Lang
%A Barak A. Pearlmutter
%T Oaklisp: an Object-Oriented Scheme with First Class Types",
%J ACM Conference on Object-Oriented Systems, Programming,
Languages and Applications",
%P 30-37
%D September 1986
%A R. Kent Dybvig
%T The Scheme Programming Language
%I Prentice-Hall, Inc.
%C Englewood Cliffs, New Jersey
%D 1987
%K splang
%A Marc Feeley
%A Guy LaPalme
%T Using Closures for Code Generation
%J Journal of Computer Languages
%V 12
%N 1
%P 47-66
%I Pergamon Press
%D 1987
%A Matthias Felleisen
%T Reflections on Landin's J-Operator: A Partly Historical Note
%J Journal of Computer Languages
%V 12
%N 3/4
%P 197-207
%I Pergamon Press
%D 1987
%A Matthias Felleisen
%A Daniel P. Friedman
%T A Reduction Semantics for Imperative Higher-Order Languages
%J Parallel Architectures and Languages Europe
%E De Bakker, Nijman and Treleaven
%B Lecture Notes in Computer Science
%V 259
%I Springer-Verlag
%C Berlin
%P 206-223
%D 1987
%A Matthias Felleisen
%A Daniel P. Friedman
%A Eugene E. Kohlbecker
%A Bruce Duba
%T A syntactic theory of sequential control
%J Theoretical Computer Science
%V 52
%P 205-237
%D 1987
%A Daniel P. Friedman
%A Matthias Felleisen
%T The Little LISPer
%I MIT Press
%D 1987
%O Trade Edition
%K littlelisper
%A Christopher T. Haynes
%A Daniel P. Friedman
%T Abstracting Timed Preemption with Engines
%J Journal of Computer Languages
%V 12
%N 2
%P 109-121
%I Pergamon Press
%D 1987
%K engines
%A R. Kent Dybvig
%T Three Implementation Models for Scheme
%R Department of Computer Science Technical Report #87-011 (Ph.D. Dissertation)
%I University of North Carolina at Chapel Hill
%C Chapel Hill, North Carolina
%D April 1987
%A Matthias Felleisen
%T The Calculi of lambda-v-cs conversion: a syntactic
theory of control and state in imperative higher-order programming
languages
%R Computer Science Technical Report #226. (Ph.D. Dissertation)
%I Indiana University
%C Bloomington, Indiana
%D August 1987
%A James S. Miller
%T A Parallel Processing System Based on MIT Scheme
%I MIT LCS Technical Report #402 (Ph.D. Dissertation)
%C Cambridge, Mass.
%D August 1987
%A Matthias Felleisen
%A Daniel P. Friedman
%A Bruce Duba
%A John Merrill
%T Beyond Continuations
%R Computer Science Dept. Technical Report #216
%I Indiana University
%C Bloomington, Indiana
%D February, 1987
%A Matthias Felleisen
%A Daniel P. Friedman
%T A calculus for assignments in higher-order languages
%J Conference Record of the 14th Annual ACM Symposium on Principles of
Programming Languages
%C Munich, West Germany
%P 314-345
%D January 1987
%A Matthias Felleisen
%A Daniel P. Friedman
%T A Syntactic Theory of Sequential State
%R Computer Science Dept. Technical Report #230
%I Indiana University
%C Bloomington, Indiana
%D October 1987
%A Christopher T. Haynes
%A Daniel P. Friedman
%T Embedding continuations in procedural objects
%J ACM Transactions on Programming Languages and Systems
%V 9
%N 4
%P 582-598
%D October 1987
%A Michael Eisenberg
%T Programming In Scheme
%E Harold Abelson
%I Scientific Press
%C Redwood City, CA
%D 1988
%A David Kranz
%T Orbit: An optimizing compiler for Scheme
%R Computer Science Technical report #632 (Ph.D. Dissertation)
%I Yale University
%D 1988
%K orbit-thesis
%A Mitchell Wand
%A Daniel P. Friedman
%T The Mystery of the Tower Revealed: A Non-Reflective
Description of the Reflective Tower
%B Meta-Level Architectures and Reflection
%E P. Maes and D. Nardi
%I Elsevier Sci. Publishers B.V. (North Holland)
%P 111-134
%D 1988
%O Also to appear in Lisp and Symbolic Computation
%A Daniel P. Friedman
%A Mitchell Wand
%A Christopher T. Haynes
%A Eugene E. Kohlbecker
%B Programming Languages: Their Abstractions, Representations,
and Implementations
%I MIT Press and McGraw-Hill
%D 1988-1989
%O in progress
%A Norman Adams
%A Jonathan Rees
%T Object-Oriented Programming in Scheme
%J Conference Record of the 1988 ACM Conference on Lisp
and Functional Programming
%P 277-288
%D August 1988
%K oopinscheme
%A William D. Clinger
%A Anne H. Hartheimer
%A Eric M. Ost
%T Implementation Strategies for Continuations
%J Conference Record of the 1988 ACM Conference on Lisp
and Functional Programming
%P 124 131
%D August 1988
%K contimpl
%A Harold Abelson
%A Gerald Jay Sussman
%T Lisp: A Language for Stratified Design
%J BYTE
%D February 1988
%P 207-218
%A William Clinger
%T Semantics of Scheme
%J BYTE
%D February 1988
%P 221-227
%A Alan Bawden
%A Jonathan Rees
%T Syntactic Closures
%J Proceedings of the 1988 ACM Symposium on LISP
and Functional Programming
%C Salt Lake City, Utah.
%D July 1988
%K macrology
%A R. Kent Dybvig
%A Robert Hieb
%T A Variable-Arity Procedural Interface
%J Proceedings of the 1988 ACM Symposium on LISP and Functional Programming
%C Salt Lake City, Utah
%D July 1988
%P 106-115
%O Also Indiana University Computer Science Department Technical Report #247
%A Matthias Felleisen
%A Mitchell Wand
%A Daniel P. Friedman
%A Bruce Duba
%T Abstract Continuations: A Mathematical Semantics for
Handling Functional Jumps
%J Proceedings of the 1988 ACM Symposium on LISP
and Functional Programming
%C Salt Lake City, Utah.
%D July 1988
%A R. Kent Dybvig
%A Daniel P. Friedman
%A Christopher T. Haynes
%T Expansion-Passing Style: A General Macro Mechanism
%J Lisp and Symbolic Computation: An International Journal
%V 1
%N 1
%I Kluwer Academic Publishers
%P 53-76
%D June 1988
%A Olin Shivers
%T Control Flow Analysis in Scheme
%J Proceedings of the Sigplan 1988 Conference on Programming Language
Design and Implementation
%P 164-174
%C Atlanta, Georgia
%D June 1988
%K schflow
%A John Franco
%A Daniel P. Friedman
%T Creating Efficient Programs by Exchanging Data for Procedures
%R Computer Science Technical Report #245
%I Indiana University
%C Bloomington, Indiana
%D March 1988
%A Kevin J. Lang
%A Barak A. Pearlmutter
%T Oaklisp: an Object-Oriented Dialect of Scheme
%J Lisp and Symbolic Computation: An International Journal
%V 1
%N 1
%I Kluwer Academic Publishers
%P 39-51
%D May 1988
%K oaklisp
%A R. Kent Dybvig
%A Robert Hieb
%T Engines from Continuations
%J Journal of Computer Languages
%V 14
%N 2
%P 109-123
%D 1989
%O Also Indiana University Computer Science Department Technical Report #254
%A George Springer
%A Daniel P. Friedman
%B Scheme and the Art of Programming
%I MIT Press and McGraw-Hill
%D 1989
%K scheme-art
%A Steven R. Vegdahl
%A Uwe F. Pleban
%T The Runtime Environment for Screme, a Scheme Implementation
on the 88000
%J Proceedings of the Third International Conference on Architectural
Support for Programming Languages and Operating Systems
%C Boston, Mass.
%D April 1989
%P 172-182
%A Joel F. Bartlett
%T SCHEME->C a Portable Scheme-to-C Compiler
%R Research Report 89/1
%I DEC Western Research Laboratory
%C Palo Alto, California
%D January 1989
%A Jonathan Rees
%T Modular Macros
%I Master's thesis, MIT Department of Electrical Engineering and
Computer Science
%D May 1989
%K modmac
%A Williams Ludwell Harrison III
%T The Interprocedural Analysis and Automatic Parallellization
of Scheme Programs
%J Lisp and Symbolic Computation: An International Journal
%V 2
%N 3/4
%I Kluwer Academic Publishers
%D October 1989
%A John Franco
%A Daniel P. Friedman
%T Towards A Facility for Lexically Scoped, Dynamic Mutual Recursion
in Scheme
%J Journal of Computer Languages
%V 15
%N 1
%P 55-64
%I Pergamon Press
%D 1990
%A Kurt Normark
%T Simulation of Object-Oriented Concepts and Mechanisms in Scheme
%R Institute for Electronic Systems Technical Report 90-01
%I Aalborg University
%C Aalborg, Denmark
%D January 1990
%K oopmech
%A Dorai Sitaram
%A Matthias Felleisen
%T Control Delimiters and Their Hierarchies
%J Lisp and Symbolic Computation: An International Journal
%V 3
%N 1
%I Kluwer Academic Publishers
%P 67-99
%D January 1990
%K ctrldelim
%A Pavel Curtis
%A James Rauen
%T A Module System for Scheme
%J Proceedings of the 1990 ACM Conference on Lisp
and Functional Programming
%C Nice, France
%D June 1990
%K module
%A Marc Feeley
%A James S. Miller
%T A Parallel Virtual Machine for Efficient Scheme Compilation
%J Proceedings of the 1990 ACM Conference on Lisp
and Functional Programming
%C Nice, France
%D June 1990
%A R. Kent Dybvig
%A Robert Hieb
%T Continuations and Concurrency
%J Proceedings of the Second ACM SIGPLAN Symposium on
Principles and Practice of Parallel Programming
%C Seattle, Washington
%D March 1990
%P 128-136
%O Also Indiana University Computer Science Department Technical Report #256
%A R. Kent Dybvig
%A Robert Hieb
%T A New Approach to Procedures with Variable Arity
%J Lisp and Symbolic Computation: An International Journal
%V 3
%N 3
%I Kluwer Academic Publishers
%D September 1990
%P 229-244
%A Robert Hieb
%A R. Kent Dybvig
%A Carl Bruggeman
%T Representing Control in the Presence of First-Class Continuations
%J Proceedings of the SIGPLAN '90 Conference on
Programming Language Design and Implementation
%C White Plains, New York
%D June 1990 (to appear)
--
First learn your horn and all the theory. Internet: oz@nexus.yorku.ca
Next develop a style. Then forget all that uucp: utzoo/utai!yunexus!oz
and just play. Charlie Parker [?] York U. CCS: (416) 736 5257
------------------------------
End of Scheme Digest
********************
∂29-May-90 2324 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #383
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 29 May 90 23:24:07 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA07020; Wed, 30 May 90 02:22:29 EDT
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Wed, 30 May 90 02:20:09 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa00533;
30 May 90 2:17 EDT
Message-Id: <DIGEST.184.900530.021022.18@MC.LCS.MIT.EDU>
Date: 30 May 90 02:10:22 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #383
Scheme Digest #383 30 May 90 02:10:22 EDT
Today's Topics:
scheme biblio. (was Re: LeLisp...)
----------------------------------------------------------------------
Message-ID: <11240@yunexus.UUCP>
Date: 27 May 90 17:59:20 GMT
From: Ozan Yigit <snorkelwacker!tut.cis.ohio-state.edu!cs.utexas.edu!news-server.csri.toronto.edu!torsqnt!lethe!yunexus!oz@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: scheme biblio. (was Re: LeLisp...)
In article <2576@skye.ed.ac.uk> jeff@aiai.UUCP (Jeff Dalton) writes:
[I assume this is about the language "definition" as in R↑nRS]
>As for Scheme, it still lacks such things as macros, modules,
>condition handling, and even the ability to define new (disjoint)
>types; many people would like to use Lisps that have such features
>rather than wait for Scheme to do it right.
If anything is worth doing right, it is also worth waiting for.
Scheme people do not just add features to the language for the sake of it.
They experiment with these things, and try to carefully select only those
things that make sense and capture the required functionality without
being gratuitous or redundant. It takes time to know what *not* to add.
This seems to be a good time to re-post the scheme bibliography (bib/refer
version). As usual, I would welcome any additions, comments, etc. you may
have. Updates to this biblio regularly appear in the Lisp Pointers.
enjoy... oz
------------------
%A John Reynolds
%T Definitional Interpreters for Higher Order Programming Languages
%J ACM Conference Proceedings
%P 717-740
%I ACM
%D 1972
%A Gerald Jay Sussman
%A Guy Lewis Steele Jr.
%T Scheme: an Interpreter for Extended Lambda Calculus
%R MIT Artificial Intelligence Memo 349
%C Cambridge, Mass.
%D December 1975
%A Guy Lewis Steele Jr.
%A Gerald Jay Sussman
%T Lambda, the Ultimate Imperative
%R MIT Artificial Intelligence Memo 353
%C Cambridge, Mass.
%D March 1976
%K imperative
%A Guy Lewis Steele Jr.
%T Lambda, the Ultimate Declarative
%R MIT Artificial Intelligence Memo 379
%C Cambridge, Mass.
%D November 1976
%K declarative
%A Guy Lewis Steele Jr.
%T Debunking the ``Expensive Procedure Call'' Myth, or Procedure Call
Implementations Considered Harmful, or LAMBDA, the Ultimate GOTO
%J ACM Conference Proceedings
%P 153-162
%I ACM
%D 1977
%K ultimate
%A Guy Lewis Steele Jr.
%T Macaroni is Better than Spaghetti
%J Proceedings of the Symposium on Artificial Intelligence and
Programming Languages
%P 60-66
%O Special joint issue of SIGPLAN Notices 12(8) and SIGART Newsletter 64
%D August 1977
%K macaroni
%A Mitchell Wand
%T Continuation-Based Program Transformation Strategies
%J Journal of the ACM
%V 27
%N 1
%P 174-180
%D 1978
%A Mitchell Wand
%A Daniel P. Friedman
%T Compiling lambda expressions using continuations and
factorizations
%J Journal of Computer Languages
%V 3
%P 241-263
%D 1978
%A Guy Lewis Steele Jr.
%A Gerald Jay Sussman
%T The Revised Report on Scheme, a Dialect of Lisp
%R MIT Artificial Intelligence Memo 452
%C Cambridge, Mass.
%D January 1978
%K r-report
%A Guy Lewis Steele Jr.
%T Rabbit: a Compiler for Scheme
%R MIT Artificial Intelligence Laboratory Technical Report 474
%C Cambridge, Mass.
%D May 1978
%K rabbit
%A Guy Lewis Steele Jr.
%A Gerald Jay Sussman
%T The Art of the Interpreter, or the Modularity Complex
(parts zero, one, and two)
%R MIT Artificial Intelligence Memo 453
%C Cambridge, Mass.
%D May 1978
%K modularity
%A Uwe F. Pleban
%T The Standard Semantics of a Subset of SCHEME, a Dialect of LISP
%R Computer Science Technical Report TR-79-3
%I University of Kansas
%C Lawrence, Kansas
%D July 1979
%A Guy Lewis Steele Jr.
%T Compiler Optimization Based on Viewing LAMBDA as RENAME + GOTO
%B AI: An MIT Perspective
%E Patrick Henry Winston
%E Richard Henry Brown
%I MIT Press
%C Cambridge, Mass.
%D 1980
%K rename+goto
%A Guy Lewis Steele Jr.
%A Gerald Jay Sussman
%T The Dream of a Lifetime: a Lazy Variable Extent Mechanism
%J Conference Record of the 1980 Lisp Conference
%P 163-172
%I The Lisp Conference
%D 1980
%K lazy
%A Drew McDermott
%T An Efficient Environment Allocation Scheme in an Interpreter
for a Lexically-Scoped Lisp
%J Conference Record of the 1980 Lisp Conference
%P 154-162
%I The Lisp Conference, P.O. Box 487, Redwood Estates CA.
%D 1980
%O Proceedings reprinted by ACM
%A Steven S. Muchnick
%A Uwe F. Pleban
%T A Semantic Comparison of Lisp and Scheme
%J Conference Record of the 1980 Lisp Conference
%P 56-65
%I The Lisp Conference, P.O. Box 487, Redwood Estates CA.
%D 1980
%A Uwe F. Pleban
%T A Denotational Approach to Flow Analysis and Optimization of
SCHEME, A Dialect of LISP
%R Ph.D. Dissertation
%I University of Kansas
%C Lawrence, Kansas
%D 1980
%A Mitchell Wand
%T Continuation-Based Multiprocessing
%J Conference Record of the 1980 Lisp Conference
%P 19-28
%I The Lisp Conference
%D 1980
%A Mitchell Wand
%T SCHEME Version 3.1 Reference Manual
%R Computer Science Technical Report 93
%I Indiana University
%C Bloomington, Indiana
%D June 1980
%K scheme3.1
%A Guy Lewis Steele Jr.
%A Gerald Jay Sussman
%T Design of a Lisp-based Processor
%J CACM
%V 23
%N 11
%P 628-645
%D November 1980
%A Rex A. Dwyer
%A R. Kent Dybvig
%T A SCHEME for Distributed Processes
%R Computer Science Department Technical Report #107
%I Indiana University
%C Bloomington, Indiana
%D April 1981
%A Gerald Jay Sussman
%A Jack Holloway
%A Guy Lewis Steele Jr.
%A Alan Bell
%T Scheme-79 - Lisp on a Chip
%J IEEE Computer
%V 14
%N 7
%P 10-21
%D July 1981
%I IEEE
%K scheme79
%A John Batali
%A Edmund Goodhue
%A Chris Hanson
%A Howie Shrobe
%A Richard M. Stallman
%A Gerald Jay Sussman
%T The Scheme-81 Architecture - System and Chip
%J Proceedings, Conference on Advanced Research in VLSI
%P 69-77
%E Paul Penfield, Jr.
%C Artech House, Dedham MA.
%D 1982
%K scheme81
%A Jonathan A. Rees
%A Norman I. Adams
%T T: A Dialect of Lisp or, LAMBDA: The Ultimate Software Tool
%J Conference Record of the 1982 ACM Symposium on Lisp and
Functional Programming
%P 114-122
%D 1982
%K T
%A Gerald Jay Sussman
%T LISP, Programming and Implementation
%B Functional Programming and its Applications
%E Darlington, Henderson, Turner
%I Cambridge University Press
%C London
%D 1982
%A R. Kent Dybvig
%T C-Scheme
%R Computer Science Department Technical Report #149 (MS Thesis)
%I Indiana University
%C Bloomington, Indiana
%D 1983
%A Pee Hong Chen
%A W.Y. Chi
%A E.M. Ost
%A L.D. Sabbagh
%A G. Springer
%T Scheme Graphics Reference Manual
%R Computer Science Technical Report No. 145
%I Indiana University
%C Bloomington, Indiana
%D August 1983
%A Pee Hong Chen
%A Daniel P. Friedman
%T Prototyping data flow by translation into Scheme
%R Computer Science Technical Report #147
%I Indiana University
%C Bloomington, Indiana
%D August 1983
%A Carol Fessenden
%A William Clinger
%A Daniel P. Friedman
%A Christopher T. Haynes
%T Scheme 311 version 4 Reference Manual
%R Computer Science Technical Report 137
%I Indiana University
%C Bloomington, Indiana
%D February 1983
%O Superceded by Computer Science Technical Report 153, 1985
%K scheme311
%A William Clinger
%T The Scheme 311 compiler: An Exercise in Denotational Semantics
%J Conference Record of the 1984 ACM Symposium on Lisp and
Functional Programming
%P 356-364
%D 1984
%K compile311
%A Daniel P. Friedman
%A Christopher T. Haynes
%A Eugene E. Kohlbecker
%T Programming with Continuations
%B Program Transformation and Programming Environments
%P 263-274
%E P. Pepper
%I Springer-Verlag
%D 1984
%A Christopher T. Haynes
%A Daniel P. Friedman
%T Engines Build Process Abstractions
%J Conference Record of the 1984 ACM Symposium on Lisp and
Functional Programming
%C Austin, TX.
%P 18-24
%D 1984
%A Christopher T. Haynes
%A Daniel P. Friedman
%A Mitchell Wand
%T Continuations and Coroutines
%J Conference Record of the 1984 ACM Symposium on Lisp and
Functional Programming
%C Austin, TX.
%P 293-298
%D 1984
%A Daniel P. Friedman
%A Mitchell Wand
%T Reification: reflection without metaphysics
%J Conference Record of the 1984 ACM Symposium on LISP and Functional
Programming
%C Austin, TX.
%P 348-355
%D August 1984
%A Jonathan A. Rees
%A Norman I. Adams
%A James R. Meehan
%T The T manual, fourth edition
%I Yale University Computer Science Department
%D January 1984
%A Guillermo J. Rozas
%T Liar, an Algol-like Compiler for Scheme
%I S. B. Thesis, MIT Department of Electrical Engineering and Computer
Science
%D January 1984
%K liar
%A Richard Schooler
%A James W. Stamos
%T Proposal For a Small Scheme Implementation
%R MIT Lab for Computer Science Memo TM-267
%C Cambridge, Mass.
%D October 1984
%T MIT Scheme Manual, Seventh Edition
%I Department of Electrical Engineering and Computer Science, MIT
%C Cambridge, Mass.
%D September 1984
%K mitscheme
%T MacScheme Reference Manual
%I Semantic Microsystems
%C Sausalito, California
%D 1985
%K macscheme
%A Harold Abelson
%A Gerald Jay Sussman
%A Julie Sussman
%T Structure and Interpretation of Computer Programs
%I MIT Press
%C Cambridge, Mass.
%D 1985
%K siocp
%A William Clinger
%A Daniel P. Friedman
%A Mitchell Wand
%T A Scheme for a Higher-Level Semantic Algebra
%B Algebraic Methods in Semantics
%E J. Reynolds, M. Nivat
%P 237-250
%I Cambridge University Press
%C London
%D 1985
%A Amitabh Srivastava
%A Don Oxley
%A Aditya Srivastava
%T An (other) Integration of Logic and Functional Programming
%J Proceedings of the Symposium on Logic Programming
%P 254-260
%I IEEE
%D 1985
%E William Clinger
%T The Revised Revised Report on Scheme, or An Uncommon Lisp
%R MIT Artificial Intelligence Memo 848
%C Cambridge, Mass.
%O Also published as Computer Science Department Technical Report 174,
Indiana University, June 1985
%D August 1985
%K rrrs
%A Daniel P. Friedman
%A Christopher T. Haynes
%T Constraining Control
%J Proceedings of the Twelfth Annual Symposium on Principles of
Programming Languages
%C New Orleans, LA.
%P 245-254
%I ACM
%D January 1985
%A Daniel P. Friedman
%A Christopher T. Haynes
%A Eugene E. Kohlbecker
%A Mitchell Wand
%T Scheme 84 Interim Reference Manual
%R Computer Science Technical Report 153
%I Indiana University
%C Bloomington, Indiana
%D January 1985
%K scheme84
%A Peehong Chen
%A L. David Sabbagh
%T Scheme as an Interactive Graphics Programming Environment
%R Computer Science Technical Report No. 166
%I Indiana University
%C Bloomington, Indiana
%D March 1985
%A R. Kent Dybvig
%A Bruce T. Smith
%T Chez Scheme Reference Manual Version 1.0
%I Cadence Research Systems
%C Bloomington, Indiana
%D May 1985
%T TI Scheme Language Reference Manual
%I Texas Instruments, Inc.
%O Preliminary version 1.0
%D November 1985
%A Michael A. Eisenberg
%T Bochser: An Integrated Scheme Programming System
%R MIT Computer Science Technical Report 349
%C Cambridge, Mass.
%D October 1985
%K bochser
%T Transliterating Prolog into Scheme
%A Matthias Felleisen
%R Computer Science Technical Report #182
%I Indiana University
%C Bloomington, Indiana
%D October 1985
%A David H. Bartley
%A John C. Jensen
%T The Implementation of PC Scheme
%J Proceedings of the 1986 ACM Conference on Lisp
and Functional Programming
%P 86-93
%D 1986
%K pcscheme
%A R. Kent Dybvig
%A Daniel P. Friedman
%A Christopher T. Haynes
%T Expansion-Passing style: Beyond Conventional Macros
%J Conference Record of the 1986 ACM Conference on Lisp and
Functional Programming
%P 143-150
%D 1986
%A Marc Feeley
%A Guy LaPalme
%T Closure Generation based on viewing LAMBDA as EPSILON plus COMPILE
%O Submitted for Publication
%D 1986
%A Matthias Felleisen
%A Daniel P. Friedman
%T A Closer Look At Export and Import Statements
%J Journal of Computer Languages
%V 11
%N 1
%P 29-37
%I Pergamon Press
%D 1986
%A Daniel P. Friedman
%A Matthias Felleisen
%T The Little LISPer: Second Edition
%I Science Research Associates, Inc.
%C Palo Alto, California
%D 1986
%A Christopher T. Haynes
%A Daniel P. Friedman
%A Mitchell Wand
%T Obtaining Coroutines With Continuations
%J Journal of Computer Languages
%V 11
%N 3/4
%P 143-153
%I Pergamon Press
%D 1986
%A Mitchell Wand
%T From Interpreter to Compiler: A Representational Derivation
%B Programs as Data Objects
%I Springer-Verlag Lecture Notes
%D 1986
%A Mitchell Wand
%T Finding the Source of Type Errors
%J Conference Record of the Thirteenth Annual Symposium on
Principles of Programming Languages
%P 38-43
%I ACM
%C St. Peterburg, Fla.
%D 1986
%A Matthias Felleisen
%A Daniel P. Friedman
%T Control operators, the SECD-machine, and the lambda-calculus
%J 3rd Working Conference on the Formal Description of
Programming Concepts
%C Ebberup, Denmark
%P 193-219
%D August 1986
%A Eugene E. Kohlbecker
%T Syntactic Extensions in the Programming Language Lisp
%R Computer Science Technical Report #199 (Ph.D. Dissertation)
%I Indiana University
%C Bloomington, Indiana
%D August 1986
%A Eugene E. Kohlbecker
%A Daniel P. Friedman
%A Matthias Felleisen
%A Bruce Duba
%T Hygienic macro expansion
%J Symposium on LISP and Functional Programming
%P 151-161
%D August 1986
%O To appear in Lisp and Symbolic Computation
%K hygienic
%A Mitchell Wand
%T The mystery of the tower revealed: a non-reflective
description of the reflective tower
%J Proceedings of the 1986 ACM Symposium on LISP and Functional Programming
%P 298-307
%D August 1986
%K tower
%E Jonathan A. Rees
%E William Clinger
%T Revised↑3 Report on the Algorithmic Language Scheme
%J ACM Sigplan Notices
%V 21
%N 12
%D December 1986
%K rrrrs
%A Christopher T. Haynes
%T Logic Continuations
%J Proceedings of the Third International Conference on
Logic Programming
%P 671-685
%I Springer-Verlag
%D July 1986
%A Matthias Felleisen
%A Daniel P. Friedman
%A Eugene E. Kohlbecker
%A Bruce Duba
%T Reasoning with Continuations
%J Proceedings of the Symposium on Logic in Computer Science
%P 131-141
%I IEEE Computer Society Press
%C Washington DC
%D June 1986
%A David Kranz
%A Richard Kelsey
%A Jonathan A. Rees
%A Paul Hudak
%A James Philbin
%A Norman I. Adams
%T Orbit: An Optimizing Compiler for Scheme
%J Proceedings of the SIGPLAN '86 Symposium on Compiler
Construction
%P 219-233
%I ACM
%O Published as SIGPLAN Notices 21(7), July 1986
%D June 1986
%K orbit
%A Marc Feeley
%T Deux Approches a' L'implantation du Language Scheme
%I M.Sc. Thesis, De'partement d'Informatique et de Recherche
Ope'rationelle, University of Montreal
%D May 1986
%A Kevin J. Lang
%A Barak A. Pearlmutter
%T Oaklisp: an Object-Oriented Scheme with First Class Types",
%J ACM Conference on Object-Oriented Systems, Programming,
Languages and Applications",
%P 30-37
%D September 1986
%A R. Kent Dybvig
%T The Scheme Programming Language
%I Prentice-Hall, Inc.
%C Englewood Cliffs, New Jersey
%D 1987
%K splang
%A Marc Feeley
%A Guy LaPalme
%T Using Closures for Code Generation
%J Journal of Computer Languages
%V 12
%N 1
%P 47-66
%I Pergamon Press
%D 1987
%A Matthias Felleisen
%T Reflections on Landin's J-Operator: A Partly Historical Note
%J Journal of Computer Languages
%V 12
%N 3/4
%P 197-207
%I Pergamon Press
%D 1987
%A Matthias Felleisen
%A Daniel P. Friedman
%T A Reduction Semantics for Imperative Higher-Order Languages
%J Parallel Architectures and Languages Europe
%E De Bakker, Nijman and Treleaven
%B Lecture Notes in Computer Science
%V 259
%I Springer-Verlag
%C Berlin
%P 206-223
%D 1987
%A Matthias Felleisen
%A Daniel P. Friedman
%A Eugene E. Kohlbecker
%A Bruce Duba
%T A syntactic theory of sequential control
%J Theoretical Computer Science
%V 52
%P 205-237
%D 1987
%A Daniel P. Friedman
%A Matthias Felleisen
%T The Little LISPer
%I MIT Press
%D 1987
%O Trade Edition
%K littlelisper
%A Christopher T. Haynes
%A Daniel P. Friedman
%T Abstracting Timed Preemption with Engines
%J Journal of Computer Languages
%V 12
%N 2
%P 109-121
%I Pergamon Press
%D 1987
%K engines
%A R. Kent Dybvig
%T Three Implementation Models for Scheme
%R Department of Computer Science Technical Report #87-011 (Ph.D. Dissertation)
%I University of North Carolina at Chapel Hill
%C Chapel Hill, North Carolina
%D April 1987
%A Matthias Felleisen
%T The Calculi of lambda-v-cs conversion: a syntactic
theory of control and state in imperative higher-order programming
languages
%R Computer Science Technical Report #226. (Ph.D. Dissertation)
%I Indiana University
%C Bloomington, Indiana
%D August 1987
%A James S. Miller
%T A Parallel Processing System Based on MIT Scheme
%I MIT LCS Technical Report #402 (Ph.D. Dissertation)
%C Cambridge, Mass.
%D August 1987
%A Matthias Felleisen
%A Daniel P. Friedman
%A Bruce Duba
%A John Merrill
%T Beyond Continuations
%R Computer Science Dept. Technical Report #216
%I Indiana University
%C Bloomington, Indiana
%D February, 1987
%A Matthias Felleisen
%A Daniel P. Friedman
%T A calculus for assignments in higher-order languages
%J Conference Record of the 14th Annual ACM Symposium on Principles of
Programming Languages
%C Munich, West Germany
%P 314-345
%D January 1987
%A Matthias Felleisen
%A Daniel P. Friedman
%T A Syntactic Theory of Sequential State
%R Computer Science Dept. Technical Report #230
%I Indiana University
%C Bloomington, Indiana
%D October 1987
%A Christopher T. Haynes
%A Daniel P. Friedman
%T Embedding continuations in procedural objects
%J ACM Transactions on Programming Languages and Systems
%V 9
%N 4
%P 582-598
%D October 1987
%A Michael Eisenberg
%T Programming In Scheme
%E Harold Abelson
%I Scientific Press
%C Redwood City, CA
%D 1988
%A David Kranz
%T Orbit: An optimizing compiler for Scheme
%R Computer Science Technical report #632 (Ph.D. Dissertation)
%I Yale University
%D 1988
%K orbit-thesis
%A Mitchell Wand
%A Daniel P. Friedman
%T The Mystery of the Tower Revealed: A Non-Reflective
Description of the Reflective Tower
%B Meta-Level Architectures and Reflection
%E P. Maes and D. Nardi
%I Elsevier Sci. Publishers B.V. (North Holland)
%P 111-134
%D 1988
%O Also to appear in Lisp and Symbolic Computation
%A Daniel P. Friedman
%A Mitchell Wand
%A Christopher T. Haynes
%A Eugene E. Kohlbecker
%B Programming Languages: Their Abstractions, Representations,
and Implementations
%I MIT Press and McGraw-Hill
%D 1988-1989
%O in progress
%A Norman Adams
%A Jonathan Rees
%T Object-Oriented Programming in Scheme
%J Conference Record of the 1988 ACM Conference on Lisp
and Functional Programming
%P 277-288
%D August 1988
%K oopinscheme
%A William D. Clinger
%A Anne H. Hartheimer
%A Eric M. Ost
%T Implementation Strategies for Continuations
%J Conference Record of the 1988 ACM Conference on Lisp
and Functional Programming
%P 124 131
%D August 1988
%K contimpl
%A Harold Abelson
%A Gerald Jay Sussman
%T Lisp: A Language for Stratified Design
%J BYTE
%D February 1988
%P 207-218
%A William Clinger
%T Semantics of Scheme
%J BYTE
%D February 1988
%P 221-227
%A Alan Bawden
%A Jonathan Rees
%T Syntactic Closures
%J Proceedings of the 1988 ACM Symposium on LISP
and Functional Programming
%C Salt Lake City, Utah.
%D July 1988
%K macrology
%A R. Kent Dybvig
%A Robert Hieb
%T A Variable-Arity Procedural Interface
%J Proceedings of the 1988 ACM Symposium on LISP and Functional Programming
%C Salt Lake City, Utah
%D July 1988
%P 106-115
%O Also Indiana University Computer Science Department Technical Report #247
%A Matthias Felleisen
%A Mitchell Wand
%A Daniel P. Friedman
%A Bruce Duba
%T Abstract Continuations: A Mathematical Semantics for
Handling Functional Jumps
%J Proceedings of the 1988 ACM Symposium on LISP
and Functional Programming
%C Salt Lake City, Utah.
%D July 1988
%A R. Kent Dybvig
%A Daniel P. Friedman
%A Christopher T. Haynes
%T Expansion-Passing Style: A General Macro Mechanism
%J Lisp and Symbolic Computation: An International Journal
%V 1
%N 1
%I Kluwer Academic Publishers
%P 53-76
%D June 1988
%A Olin Shivers
%T Control Flow Analysis in Scheme
%J Proceedings of the Sigplan 1988 Conference on Programming Language
Design and Implementation
%P 164-174
%C Atlanta, Georgia
%D June 1988
%K schflow
%A John Franco
%A Daniel P. Friedman
%T Creating Efficient Programs by Exchanging Data for Procedures
%R Computer Science Technical Report #245
%I Indiana University
%C Bloomington, Indiana
%D March 1988
%A Kevin J. Lang
%A Barak A. Pearlmutter
%T Oaklisp: an Object-Oriented Dialect of Scheme
%J Lisp and Symbolic Computation: An International Journal
%V 1
%N 1
%I Kluwer Academic Publishers
%P 39-51
%D May 1988
%K oaklisp
%A R. Kent Dybvig
%A Robert Hieb
%T Engines from Continuations
%J Journal of Computer Languages
%V 14
%N 2
%P 109-123
%D 1989
%O Also Indiana University Computer Science Department Technical Report #254
%A George Springer
%A Daniel P. Friedman
%B Scheme and the Art of Programming
%I MIT Press and McGraw-Hill
%D 1989
%K scheme-art
%A Steven R. Vegdahl
%A Uwe F. Pleban
%T The Runtime Environment for Screme, a Scheme Implementation
on the 88000
%J Proceedings of the Third International Conference on Architectural
Support for Programming Languages and Operating Systems
%C Boston, Mass.
%D April 1989
%P 172-182
%A Joel F. Bartlett
%T SCHEME->C a Portable Scheme-to-C Compiler
%R Research Report 89/1
%I DEC Western Research Laboratory
%C Palo Alto, California
%D January 1989
%A Jonathan Rees
%T Modular Macros
%I Master's thesis, MIT Department of Electrical Engineering and
Computer Science
%D May 1989
%K modmac
%A Williams Ludwell Harrison III
%T The Interprocedural Analysis and Automatic Parallellization
of Scheme Programs
%J Lisp and Symbolic Computation: An International Journal
%V 2
%N 3/4
%I Kluwer Academic Publishers
%D October 1989
%A John Franco
%A Daniel P. Friedman
%T Towards A Facility for Lexically Scoped, Dynamic Mutual Recursion
in Scheme
%J Journal of Computer Languages
%V 15
%N 1
%P 55-64
%I Pergamon Press
%D 1990
%A Kurt Normark
%T Simulation of Object-Oriented Concepts and Mechanisms in Scheme
%R Institute for Electronic Systems Technical Report 90-01
%I Aalborg University
%C Aalborg, Denmark
%D January 1990
%K oopmech
%A Dorai Sitaram
%A Matthias Felleisen
%T Control Delimiters and Their Hierarchies
%J Lisp and Symbolic Computation: An International Journal
%V 3
%N 1
%I Kluwer Academic Publishers
%P 67-99
%D January 1990
%K ctrldelim
%A Pavel Curtis
%A James Rauen
%T A Module System for Scheme
%J Proceedings of the 1990 ACM Conference on Lisp
and Functional Programming
%C Nice, France
%D June 1990
%K module
%A Marc Feeley
%A James S. Miller
%T A Parallel Virtual Machine for Efficient Scheme Compilation
%J Proceedings of the 1990 ACM Conference on Lisp
and Functional Programming
%C Nice, France
%D June 1990
%A R. Kent Dybvig
%A Robert Hieb
%T Continuations and Concurrency
%J Proceedings of the Second ACM SIGPLAN Symposium on
Principles and Practice of Parallel Programming
%C Seattle, Washington
%D March 1990
%P 128-136
%O Also Indiana University Computer Science Department Technical Report #256
%A R. Kent Dybvig
%A Robert Hieb
%T A New Approach to Procedures with Variable Arity
%J Lisp and Symbolic Computation: An International Journal
%V 3
%N 3
%I Kluwer Academic Publishers
%D September 1990
%P 229-244
%A Robert Hieb
%A R. Kent Dybvig
%A Carl Bruggeman
%T Representing Control in the Presence of First-Class Continuations
%J Proceedings of the SIGPLAN '90 Conference on
Programming Language Design and Implementation
%C White Plains, New York
%D June 1990 (to appear)
------------------------------
End of Scheme Digest
********************
∂31-May-90 0031 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #384
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 31 May 90 00:31:06 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA24169; Thu, 31 May 90 03:27:48 EDT
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Thu, 31 May 90 03:25:36 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa29487;
31 May 90 3:24 EDT
Message-Id: <DIGEST.184.900531.031023.24@MC.LCS.MIT.EDU>
Date: 31 May 90 03:10:23 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #384
Scheme Digest #384 31 May 90 03:10:23 EDT
Today's Topics:
why is quasiquote necessary? (2 messages)
Is there a public domain Scheme
----------------------------------------------------------------------
Message-ID: <ALMS.90May30153205@brazil.cambridge.apple.com>
Date: 30 May 90 19:32:05 GMT
From: "Andrew L. M. Shalit" <cambridge.apple.com!alms@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: why is quasiquote necessary?
It occurred to me today that Scheme doesn't really need a quasiquote
special form. Instead, quote could have just been extended to handle
unquote and unquote-splicing.
I can only think of two reasons for having both quote and quasiquote:
1) historical accident, because of the way the quasiquote special
form was derived from a reader macro.
2) program readability. Some would argue that a large quoted piece of
program text with a little bitty comma in the middle might be prone
to misinterpretation (by humans).
-andrew
------------------------------
Message-ID: <6282@tekcrl.LABS.TEK.COM>
Date: 31 May 90 00:59:40 GMT
From: Ken Dickey <zephyr.ens.tek.com!tekcrl!tekchips!kend@uunet.uu.net>
To: scheme@mc.lcs.mit.edu
Subject: Re: why is quasiquote necessary?
In article <ALMS.90May30153205@brazil.cambridge.apple.com> alms@cambridge.apple.com (Andrew L. M. Shalit) writes:
>
>It occurred to me today that Scheme doesn't really need a quasiquote
>special form. Instead, quote could have just been extended to handle
>unquote and unquote-splicing.
Quoted data is constant [e.g. EPROMable]. My recollection is that
quasi-quoted forms may expand into something not quite constant.
I can't immediately think of a good example [nested quasi-quotes?]
{JAR, are you out there?}.
-Ken Dickey kend@mrloog.WR.TEK.COM
------------------------------
Message-ID: <COWAN.90May30211308@altair.aero.org>
Date: 31 May 90 04:13:08 GMT
From: Ric Cowan <sdd.hp.com!samsung!usc!aero!cowan@think.com>
To: scheme@mc.lcs.mit.edu
Subject: Is there a public domain Scheme
that runs on Sun 4s (or less desirable, Sun 3s)?
Thanks in advance.
--
Ric
------------------------------
End of Scheme Digest
********************
∂31-May-90 2342 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #385
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 31 May 90 23:42:11 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA12255; Fri, 1 Jun 90 02:41:00 EDT
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Fri, 1 Jun 90 02:38:37 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22296;
1 Jun 90 2:40 EDT
Message-Id: <DIGEST.184.900601.024023.28@MC.LCS.MIT.EDU>
Date: 1 Jun 90 02:40:22 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #385
Scheme Digest #385 1 Jun 90 02:40:22 EDT
Today's Topics:
C0WABUNGA!!
Turtle Graphics and X?
using SCIX (2 messages)
why is quasiquote necessary?
----------------------------------------------------------------------
Message-ID: <901506974183BIFF@BIFFVM.BIT.NET>
Date: 31 May 90 12:34:02 GMT
From: THE BIFFMAN COMETH <usc!uscd!uwm!zaphod.cs.ohio-state!HERE!THERE!EVERYWHERE!BIFF@ucbvax.berkeley.edu>
To: scheme@mc.lcs.mit.edu
Subject: C0WABUNGA!!
HIYA D00DS!! ICUZ MY BBROTHER <--BIG BROTHER, NEET HUH? WUZ BBSITTING ME AND MY
MOM WULD KILL HIM IF ANYTING HAPENED TO ME. THEES SHUR R
NIFTY BBOARDS!! IZ ANYWON MODURATING THEM?? I CAN DO IT D00DS!!
I PROVED MY BABAILITY BY MODURATING NEWS.GROUPS. SO FROM NOW ON
IC0WABUNGA!!
------
BIFF@BIFFVM.BIT.NET
BIFF+@ANDREW.CMU.EDU
BIFF@BIT.NET.GATE.WAY.MAN.WOMAN.BIRTH.DEATH.ALPHA.OMEGA.BIFF
------------------------------
Message-ID: <1990May31.134209.18475@ncsuvx.ncsu.edu>
Date: 31 May 90 13:42:09 GMT
From: "John W. Baugh Jr." <news@ncsuvx.ncsu.edu>
To: scheme@mc.lcs.mit.edu
Subject: Turtle Graphics and X?
I posted this on comp.windows.x yesterday--I'm not sure
where it belongs. After thinking about it, I'd actually
prefer a scheme implementation if such a thing exists.
---
I've been reading Abelson's _Turtle_Geometry_ with interest.
Do any lisp- or logo-like interpreters with Turtle graphics
exist on X and Unix? Also, turtle geometry is new to me--
anyone care to make any comments about it, newer references,
implementations, ...?
John Baugh
jwb@cepmax.ncsu.edu
------------------------------
Message-ID: <2087@male.EBay.Sun.COM>
Date: 31 May 90 21:34:34 GMT
From: Garey Mills <bu.edu!rpi!zaphod.mps.ohio-state.edu!usc!apple!sun-barr!newstop!male!garey@bloom-beacon.mit.edu>
To: scheme@MC.lcs.mit.edu
Subject: using SCIX
Can anyone help me with a problem I am having using
SCIX? I have something written in Scheme using the
HWOOPS package and I want to compile it to C using
the Scheme-to-C compiler. The compiler gives up on
the 'define-class.sc' macro included in the SCIX
package. Am I doing something wrong? Should I be
creating an intermediate file using the define-class
macro (and how do I do that?)? Any help would be
appreciated.
Garey Mills
------------------------------
Message-ID: <JOHANI.90Jun1023022@mowitz.nada.kth.se>
Date: 1 Jun 90 00:30:36 GMT
From: Johan Ihren <eru!luth!sunic!kth.se!news@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: using SCIX
In <2087@male.EBay.Sun.COM> garey@gtm.EBay.Sun.COM (Garey Mills) writes:
> Can anyone help me with a problem I am having using
> SCIX? I have something written in Scheme using the
> HWOOPS package and I want to compile it to C using
> the Scheme-to-C compiler. The compiler gives up on
> the 'define-class.sc' macro included in the SCIX
> package. Am I doing something wrong?
Hard to say without more information, but it doesn't sound like it.
Strange, though, that the compiler barfs on define-class after having
evaluated it lots of times when compiling the system...
> Should I be
> creating an intermediate file using the define-class
> macro (and how do I do that?)?
If what you mean is "should I compile define-class separately" then
the answer is no, as it is not possible to compile a macro. It is
only possible to compile something that has been expanded by a macro.
> Any help would be appreciated.
Send the files to scix@nada.kth.se and we'll look into it.
PS. SCIX version 0.97 is due before the end of June. It has been
delayed because we've had to concentrate on exams in other subjects
for a while...
Johan Ihren
Dept. of Computer Science,
Royal Institute of Technology, Stockholm, Sweden
Email: johani@nada.kth.se -or- <backbone>!sunic!nada!johani
------------------------------
Message-ID: <1990May31.214540.21763@sq.sq.com>
Date: 31 May 90 21:45:40 GMT
From: David A Keldsen <attcan!lsuc!sq!dak@uunet.uu.net>
To: scheme@mc.lcs.mit.edu
Subject: Re: why is quasiquote necessary?
alms@cambridge.apple.com (Andrew L. M. Shalit) writes:
>It occurred to me today that Scheme doesn't really need a quasiquote
>special form. Instead, quote could have just been extended to handle
>unquote and unquote-splicing.
>I can only think of two reasons for having both quote and quasiquote:
> 1) historical accident, because of the way the quasiquote special
> form was derived from a reader macro.
> 2) program readability. Some would argue that a large quoted piece of
> program text with a little bitty comma in the middle might be prone
> to misinterpretation (by humans).
I respectfully disagree [that Scheme doesn't need the quote-quasiquote
distinction]. This (IMHO) is one of those places where full generality
is *not* a good thing. In particular, both human and machine readers
of quasiquoted phrases must scan the *entire* phrase, looking for
unquotes...which is an efficiency loss. Quote allows one to say, "OK,
stop looking, the rest is unevaluated." It's a common enough case that
it is worth the difference in notation.
> -andrew
--
// David A. 'Dak' Keldsen: dak@sq.com or utai[.toronto.edu]!sq!dak
// "I have heard the mermaids singing, each to each." -- T.S.Eliot
------------------------------
End of Scheme Digest
********************
∂02-Jun-90 1208 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #386
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 2 Jun 90 12:08:00 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA06555; Sat, 2 Jun 90 15:07:48 EDT
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Sat, 2 Jun 90 15:05:34 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa16364;
2 Jun 90 14:28 EDT
Message-Id: <DIGEST.184.900602.022523.32@MC.LCS.MIT.EDU>
Date: 2 Jun 90 02:25:22 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #386
Scheme Digest #386 2 Jun 90 02:25:22 EDT
Today's Topics:
Minimum hardware for PC-Scheme
----------------------------------------------------------------------
Message-ID: <9639@sbcs.sunysb.edu>
Date: 1 Jun 90 15:12:55 GMT
From: KiYun Roe <sbcs!kroe@louie.udel.edu>
To: scheme@mc.lcs.mit.edu
Subject: Minimum hardware for PC-Scheme
Would someone mind telling me what the minimum hardware requirements
for PC-Scheme are? Would it run, for instance, on a Toshiba T1000SE
laptop w/o hard disk? Does it take advantage of expanded memory?
--
KiYun Roe kroe@sbcs.sunysb.edu
Department of Computer Science
SUNY at Stony Brook
Stony Brook, NY 11794-4400 (516) 632-7675
------------------------------
End of Scheme Digest
********************
∂04-Jun-90 0657 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #387
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 4 Jun 90 06:57:48 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA22371; Mon, 4 Jun 90 09:53:55 EDT
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Mon, 4 Jun 90 09:51:42 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa18510;
4 Jun 90 9:50 EDT
Message-Id: <DIGEST.184.900603.021023.36@MC.LCS.MIT.EDU>
Date: 3 Jun 90 02:10:22 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #387
Scheme Digest #387 3 Jun 90 02:10:22 EDT
Today's Topics:
why is quasiquote necessary? (3 messages)
Minimum hardware for PC-Scheme (2 messages)
----------------------------------------------------------------------
Message-ID: <9006020024.AA00349@wheat-chex>
Date: Fri, 1 Jun 90 20:24:13 EDT
From: Alan Bawden <alan@ai.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: why is quasiquote necessary?
Unfortunately
`',x
and
'`,x
don't mean the same thing.
------------------------------
Message-ID: <MAC.90Jun1094453@k9.cad.mcc.com>
Date: 1 Jun 90 14:44:53 GMT
From: Mac Michaels <samsung!cs.utexas.edu!milano!cadillac!mac@think.com>
To: scheme@mc.lcs.mit.edu
Subject: Re: why is quasiquote necessary?
alms@cambridge.apple.com (Andrew L. M. Shalit) writes:
>It occurred to me today that Scheme doesn't really need a quasiquote
>special form. Instead, quote could have just been extended to handle
>unquote and unquote-splicing.
>I can only think of two reasons for having both quote and quasiquote:
I always thought that quasiquote was there to allow Scheme code to generate
expressions that contain unquote and unquote-splicing symbols [, and ,@].
Quote does not process these symbols and thus allowing the generation of
forms containing them.
--
USPS: Mac Michaels, 3500 West Balcones Center Dr., Austin,TX 78759
ARPA: mac@mcc.com TELE: (512) 338-3509 FAX: (512) 338-3600
UUCP: {uunet,harvard,gatech,pyramid}!cs.utexas.edu!milano!cadillac!mac
:-)))))))) She had so many chins, she looked like a piece of Lisp code!
------------------------------
Message-ID: <9006011846.AA15382@verdi.think.com>
Date: Fri, 1 Jun 90 14:46:11 EDT
From: Guy Steele <gls@think.com>
To: Scheme@lcs.mit.edu
CC: Scheme@lcs.mit.edu
Subject: why is quasiquote necessary?
From: "Andrew L. M. Shalit" <cambridge.apple.com!alms@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
It occurred to me today that Scheme doesn't really need a quasiquote
special form. Instead, quote could have just been extended to handle
unquote and unquote-splicing.
I can only think of two reasons for having both quote and quasiquote:
1) historical accident, because of the way the quasiquote special
form was derived from a reader macro.
2) program readability. Some would argue that a large quoted piece of
program text with a little bitty comma in the middle might be prone
to misinterpretation (by humans).
-andrew
There are some effects that cannot be achieved using quasiquote
only. Consider, for example, an idiom I find myself using
frequently:
`',x
which means about the same as (list 'quote x).
``,x
does not mean the same thing at all because the comma
is captured by the inner quasiquote.
--Guy
------------------------------
Message-ID: <46523@iuvax.cs.indiana.edu>
Date: 2 Jun 90 17:37:28 GMT
From: Charles David Boyer <boyer@iuvax.cs.indiana.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: Minimum hardware for PC-Scheme
kroe@sbcs.sunysb.edu (KiYun Roe) writes:
>Would someone mind telling me what the minimum hardware requirements
>for PC-Scheme are? Would it run, for instance, on a Toshiba T1000SE
>laptop w/o hard disk? Does it take advantage of expanded memory?
>--
Paraphrased from the TI-Scheme manual:
- MS-DOS 2.1 (or greater) or PC-DOS 2.0 (or greater)
- 320K bytes of memory
- Dual diskette drives
Note that additional memory and a hard disk are recomended, particularly
for software development. The EDWIN text editor requires a minimum of
512L bytes of memory. Also, graphics hardware support is required to use
the graphics features of PC Scheme.
PC Scheme will use expanded or extended memory (by running different
executables) but runs fastest in standard memory.
David Boyer
------------------------------
Message-ID: <8086@ubc-cs.UUCP>
Date: 2 Jun 90 20:34:09 GMT
From: Vincent Manis <van-bc!ubc-cs!manis@uunet.uu.net>
To: scheme@mc.lcs.mit.edu
Subject: Re: Minimum hardware for PC-Scheme
I have run PC-Scheme on an original T1000, with no extra memory. You
don't have a lot of free disk space, and you can't easily use Edwin (at
least with moderately sized programs), but it does work. PC-Scheme will
use up to 2MB of memory, but it runs ok on a 512K machine.
--
\ Vincent Manis <manis@cs.ubc.ca> "There is no law that vulgarity and
\ Department of Computer Science literary excellence cannot coexist."
/\ University of British Columbia -- A. Trevor Hodge
/ \ Vancouver, BC, Canada V6T 1W5 (604) 228-2394
------------------------------
End of Scheme Digest
********************
∂06-Jun-90 0043 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #388
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 6 Jun 90 00:43:31 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA24454; Wed, 6 Jun 90 03:42:45 EDT
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Wed, 6 Jun 90 03:40:28 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa10476;
6 Jun 90 3:22 EDT
Message-Id: <DIGEST.184.900606.024024.49@MC.LCS.MIT.EDU>
Date: 6 Jun 90 02:40:24 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #388
Scheme Digest #388 6 Jun 90 02:40:24 EDT
Today's Topics:
frivolous Scheme things (Fun Only posting)
----------------------------------------------------------------------
Message-ID: <3135@husc6.harvard.edu>
Date: 5 Jun 90 18:10:07 GMT
From: david carlton <husc2!carlton@husc6.harvard.edu>
To: scheme@mc.lcs.mit.edu
Subject: frivolous Scheme things (Fun Only posting)
Here are a couple of neat little Scheme things I've come across or come
up with here at school. I hope this is not out of line for the newsgroup,
which seems to be pretty serious.
;; #1
;; By Carl Muckenhoupt
;; Put in more lambdas if you want.
(define list (lambda lambda lambda))
;; #2 Self-rep
;; This expression prints itself out.
((lambda (s) `(,s ',s))
'(lambda (s) `(,s ',s)))
;; #2b Self-rep II
;; So does this one. Which part of this one can be changed to
;; any old quoted expression?
((lambda (s t) `(,s ',s ',t))
'(lambda (s t) `(,s ',s ',t))
'(lambda (s t) `(,s ',s ',t)))
;; #3 Self-rep III (two-stage)
((lambda (s t) `(,s ',s ,(not t)))
'(lambda (s t) `(,s ',s ,(not t)))
t)
;; #3b Self-rep IV (n-stage)
((lambda (s t) `(,s ',s ,(mod (1+ t) n)))
'(lambda (s t) `(,s ',s ,(mod (1+ t) n)))
0)
;; #4 call/cc nightmare (true by definition?)
(define I (lambda (x) x))
((call/cc call/cc) I)
;; What does this return, and why?
;; How about
((call/cc call/cc) (call/cc call/cc))
If you have any tidbits like these, or improvements or variations on
these, I would *love* to see them, and would be grateful if you would
send them to me.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; Lars Huttar huttar@occs.cs.oberlin.edu Oberlin College CS
;; US mail: 206 Merribrook Trail Duncanville, TX 75116
------------------------------
End of Scheme Digest
********************
∂06-Jun-90 2357 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #389
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 6 Jun 90 23:57:31 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA11324; Thu, 7 Jun 90 02:52:08 EDT
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Thu, 7 Jun 90 02:50:04 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id ab08209;
7 Jun 90 2:38 EDT
Message-Id: <DIGEST.184.900607.022526.54@MC.LCS.MIT.EDU>
Date: 7 Jun 90 02:25:26 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #389
Scheme Digest #389 7 Jun 90 02:25:26 EDT
Today's Topics:
MacScheme (3 messages)
scoops
seeking Haskell implementation
Using PC Scheme's RUNTIME.APP file
----------------------------------------------------------------------
Message-ID: <9006061205.aa28980@mintaka.lcs.mit.edu>
Date: Wed, 6 Jun 90 09:20 CDT
From: ROWLAND%UABCMC.BITNET@mitvma.mit.edu
To: SCHEME@lcs.mit.edu
Subject: MacScheme
To: SCHEME@LCS.MIT.EDU
From: Scott Rowland
Center for Macromolecular Crystallography
University of Alabama at Birmingham
Birmingham, AL. USA
(205) 934-7974
BITNET: ROWLAND@UABCMC
Date: June 6, 1990 9:00 AM CST
Subject: MacScheme
Does anyone have an address/telephone number for Semantic Microsystems, the
developers of MacScheme?
Cheers,
scott
------------------------------
Message-ID: <CREON.90Jun5173859@wkd5.nas.nasa.gov>
Date: 6 Jun 90 00:38:59 GMT
From: Creon Levit <amelia!creon@ames.arc.nasa.gov>
To: scheme@mc.lcs.mit.edu
Subject: scoops
So where can I get scoops?
--
Creon Levit
mail stop T045-1
NASA Ames Research Center
Moffett Field, California 94035
(415)-604-4403
creon@nas.nasa.gov (Internet)
------------------------------
Message-ID: <2689@wrgate.WR.TEK.COM>
Date: 6 Jun 90 20:37:54 GMT
From: Ken Dickey <mintaka!ogicse!zephyr.ens.tek.com!wrgate!mrloog!kend@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: MacScheme
In article <9006061205.aa28980@mintaka.lcs.mit.edu> ROWLAND@UABCMC.BITNET writes:
>From: Scott Rowland
..
>Does anyone have an address/telephone number for Semantic Microsystems, the
>developers of MacScheme?
Lightship Software (was Semantic MicroSystems)
PO 1636 Blvd, Beaverton, OR 97075
(503) 643-6909
-Ken Dickey kend@mrloog.LA.TEK.COM
------------------------------
Message-ID: <9006062240.AA06612@life.ai.mit.edu>
Date: Wed, 6 Jun 90 17:34 CDT
From: ROWLAND%UABCMC.BITNET@mitvma.mit.edu
To: SCHEME@ai.mit.edu
Subject: MacScheme
To: scheme@ai.mit.edu
From: Scott Rowland
Center for Macromolecular Crystallography
University of Alabama at Birmingham
Birmingham, AL. USA
(205) 934-7970
BITNET: ROWLAND@UABCMC
Date: June 6, 1990 5:30 PM CST
Subject: MacScheme
I have been trying to contact Sematic Microsystems about there MacScheme
product with no success. The information I have is as follows:
Sematic Microsystems
4470 SW Hall Street, Suite 340
Beaverton, OR 97005
(503) 643-4539
That telephone number is now for a residence (with occupants that are
pretty pissed off about getting all these phone calls). Beaverton
information has no Sematic Microsystems listed. Does anyone know if
Sematic is still afloat and if so their location? Also are there other
implementations of Scheme on the Mac?
Thanks in advance,
scott
------------------------------
Message-ID: <SRA.90Jun5192113@alonzo.ecs.soton.ac.uk>
Date: 5 Jun 90 18:21:13 GMT
From: Stephen Adams <mcsun!ukc!icdoc!sot-ecs!sra@uunet.uu.net>
To: scheme@mc.lcs.mit.edu
Subject: seeking Haskell implementation
I am looking for a Haskell implementation. I seem to remember one
being advertised on this newsgroup but the message has expired at our
site so I cant check. I think that it was written in T.
Could someone (the implementor?) please mail me.
Many thanks
--
Stephen Adams S.Adams@uk.ac.soton.ecs (JANET)
Computer Science S.Adams@ecs.soton.ac.uk (Bitnet)
Southampton S09 5NH, UK S.Adams@sot-ecs.uucp (uucp)
------------------------------
Message-ID: <1398@doitcr.doit.sub.org>
Date: 5 Jun 90 19:40:47 GMT
From: Florian Reichl <snorkelwacker!ira.uka.de!smurf!gopnbg!altger!doitcr!flo@bloom-beacon.mit.edu>
To: scheme@MC.lcs.mit.edu
Subject: Using PC Scheme's RUNTIME.APP file
Together with the PC Scheme package from Texas Instruments
a file called RUNTIME.APP is delivered.
Someone I can't remember told me that it can be used instead
of COMPILER.APP if you want to deliver your program to some
user without violating the license agreement with TI.
Is there anybody out there who knows about this feature.
With best greetings from Bavaria -- Florian
------------------------------
End of Scheme Digest
********************
∂07-Jun-90 2345 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #390
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 7 Jun 90 23:45:20 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA13371; Fri, 8 Jun 90 02:44:39 EDT
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Fri, 8 Jun 90 02:42:15 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id ab03282;
8 Jun 90 2:36 EDT
Message-Id: <DIGEST.184.900608.021028.60@MC.LCS.MIT.EDU>
Date: 8 Jun 90 02:10:27 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #390
Scheme Digest #390 8 Jun 90 02:10:27 EDT
Today's Topics:
PC Scheme
T3.1
TI PC Scheme - how good is it?
DEVS-Scheme Availability?
indent for scheme, lisp
----------------------------------------------------------------------
Message-ID: <9006070336.aa15956@mc.lcs.mit.edu>
Date: Thu, 7 Jun 90 15:38 H
From: WONGWF%NUSDISCS.BITNET@mitvma.mit.edu
To: scheme@mc.lcs.mit.edu
Subject: PC Scheme
Hello Everyone,
First, my 2 cents worth : SCOOPS comes with PC-Scheme. My experience
with SCOOPS is that it makes debugging a little difficult - with all the
indirections, you hardly know where something fails by using the backtrace
facility.
Now, my problem ... I have been using PC Scheme 3.03 for some time
now and there have been those desperate moment where the interpreter bombs
on me without any valid reasons. The first time it happened, it gave "Timer
already running" or something like that. Well, silly me, I thought to myself,
its probably because I use ENGINES and when my program bombed, it didn't reset
the timer properly.
Some time later, I was satisfied with my program so I started removing
"writeln"s from it. It bombed. The funny thing was that I narrowed it down to
a particular "writeln" which was of no particular significance - when it is in,
the program worked, without it the program bombed. I went around it by removing
some "write-char" statements (which by the way, was important) together with
that particular "writeln". It worked - or so I thought !
Now, my program sometime works perfectly well while at other time,
WITHOUT ANY modifications, failed. It usually gives "VM Error - ()" whatever
that means. I did a backtrace but I have no reason to expect it to fail at the
place where it said it did. I am now at the conclusion that PC Scheme is
unstable ! (although I hardly know why) Or maybe I'm using the wrong version.
Anyone out there have similar experiences ? Perhaps someone could give
me some pointers.
Weng-Fai, WONG,
Dept. of Info. Sys. and Comp. Sc.,
National University of Singapore,
Lower Kent Ridge Road,
Singapore 0511.
Republic of Singapore.
email : wongwf@nusdiscs.bitnet
------------------------------
Message-ID: <788@fornax.UUCP>
Date: 5 Jun 90 19:49:07 GMT
From: Miron Cuperman <van-bc!ubc-cs!fornax!miron@ucbvax.berkeley.edu>
To: scheme@mc.lcs.mit.edu
Subject: T3.1
I have seen several people saying that they use Cscheme (from MIT) on
their Sparcs. I am wondering why aren't they using T3.1 from the
T project at Yale. I think it is a much better choice for the Sparc.
It has a very good compiler, a good debugger, and pretty complete docs.
A new version is available from:
128.52.32.13 WHEATIES.AI.MIT.EDU
in the directory pub/t3.1. The executable is in sparc.tar.Z.
I have discovered three undefined functions that have to be redefined:
(define-constant (set-car! x y) (set (car x) y))
(define-constant (set-cdr! x y) (set (cdr x) y))
(define-constant (string-set! x y z) (set (string-elt x y) z))
To go into the scheme interpreter use '(scheme-reset)'.
--
By me: Miron Cuperman <miron@cs.sfu.ca>
------------------------------
Message-ID: <1990Jun7.074442.15020@portia.Stanford.EDU>
Date: 7 Jun 90 07:44:42 GMT
From: Daniel Lichstein <eos!shelby!portia.stanford.edu!ldan@AMES.ARC.NASA.GOV>
To: scheme@mc.lcs.mit.edu
Subject: TI PC Scheme - how good is it?
I am interested in LISP programming on a IBM PC and noticed
that TI sells a cheap PC SCHEME. Does anyone know how good it is?
Specificaly I am interested in interactive manipulation of graph
structures so information on it's graphics capabilities and database
cap. would be especialy appreciated.
-------------------------------------------------------------------
From ldan@portia.stanford.edu
------------------------------
Message-ID: <3836@iitmax.IIT.EDU>
Date: 7 Jun 90 19:04:31 GMT
From: Greg Chien <snorkelwacker!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!ux1.cso.uiuc.edu!tank!iitmax!chien@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: DEVS-Scheme Availability?
Does anyone know how to get DEVS-Scheme as describe in B. P. Zeigler's
"Object-Oriented Simulation with Hierarchical, Modular Models", Acadamic
Press, 1990. Better yet, any ftp site?
Thanks in advance,
Greg Chien
Design Processes Laboratory
Institute of Design
Illinois Institute of Technology
------------------------------
Message-ID: <1990Jun7.160254.6360@sq.sq.com>
Date: 7 Jun 90 16:02:54 GMT
From: David A Keldsen <umich!samsung!cs.utexas.edu!news-server.csri.toronto.edu!utgpu!utzoo!sq!dak@yale-zoo.arpa>
To: scheme@mc.lcs.mit.edu
Subject: indent for scheme, lisp
Before I take the plunge, and re-invent the wheel, does anyone happen to
have a publically available lisp indenter available?
A pretty-printer is also of interest, but since a pretty printer acts on
previously read data forms, it will discard comments (not acceptable
for re-indenting source code, which is the application I have in mind).
Please reply by mail; I'll summarize and post.
Thanks,
Dave Keldsen
--
// David A. 'Dak' Keldsen: dak@sq.com or utai[.toronto.edu]!sq!dak
// "I have heard the mermaids singing, each to each." -- T.S.Eliot
------------------------------
End of Scheme Digest
********************
∂09-Jun-90 0019 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #391
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 9 Jun 90 00:18:52 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA01573; Sat, 9 Jun 90 03:17:29 EDT
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Sat, 9 Jun 90 03:15:03 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa00177;
9 Jun 90 3:08 EDT
Message-Id: <DIGEST.184.900609.031029.64@MC.LCS.MIT.EDU>
Date: 9 Jun 90 03:10:29 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #391
Scheme Digest #391 9 Jun 90 03:10:29 EDT
Today's Topics:
indent for scheme, lisp
----------------------------------------------------------------------
Message-ID: <1990Jun8.012626.7073@sq.sq.com>
Date: 8 Jun 90 01:26:26 GMT
From: David A Keldsen <mnetor!utzoo!sq!dak@uunet.uu.net>
To: scheme@mc.lcs.mit.edu
Subject: Re: indent for scheme, lisp
dak@sq.sq.com (David A Keldsen) writes:
>Before I take the plunge, and re-invent the wheel, does anyone happen to
>have a publically available lisp indenter available?
The responses I've gotten so far (amazingly fast, thanks folks!) show
that I need to put more constraints on this request. In particular,
this indenter has to be:
1) Stand-alone,
2) Small,
3) Portable (assume C or Scheme is available, *nothing else*)
4) Free (including of constraints, hence no GNU code).
(Don't worry, if it's PD, and I improve it,
the improvements will be PD)
Has anyone here ever thought of writing a variant of (read) [call it
(read-with-comments)] that retains comments? It would make writing a
"keeps comments" pretty printer much easier...
Again, please reply by mail; I'll summarize and post.
Thanks!
--
// David A. 'Dak' Keldsen: dak@sq.com or utai[.toronto.edu]!sq!dak
// "I have heard the mermaids singing, each to each." -- T.S.Eliot
------------------------------
End of Scheme Digest
********************
∂10-Jun-90 0002 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #392
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 10 Jun 90 00:02:25 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA09901; Sun, 10 Jun 90 03:00:54 EDT
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Sun, 10 Jun 90 02:58:30 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa14895;
10 Jun 90 2:59 EDT
Message-Id: <DIGEST.184.900610.025528.66@MC.LCS.MIT.EDU>
Date: 10 Jun 90 02:55:28 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #392
Scheme Digest #392 10 Jun 90 02:55:28 EDT
Today's Topics:
indent for scheme, lisp
calling C++ from C,Scheme,Lisp and other languages
----------------------------------------------------------------------
Message-ID: <30648@cup.portal.com>
Date: 9 Jun 90 15:57:03 GMT
From: Paul Frederick Snively <cs.utexas.edu!usc!apple!portal!cup.portal.com!Chewy@yale-zoo.arpa>
To: scheme@mc.lcs.mit.edu
Subject: Re: indent for scheme, lisp
RE: reasonable Lisp indentation algorithms...
I believe there are a couple of MIT AI Lab notes available that address this
issue. I seem to recall reading somewhere about a code formatter that even
does its job in linear time, which sounds pretty amazing to me.
In any case, off the top of my head, it seems to me that you should be able to
1) copy your Lisp's standard readtable and hack it so as not to ignore
comments, and
2) somehow integrate the results with XP, Dick Waters' highly-extensible
pretty-printing package, which is available via FTP to wheaties.ai.mit.edu.
Hope this helps!
------------------------------
Message-ID: <HAM.90Jun9201627@Neon.Stanford.EDU>
Date: 10 Jun 90 03:16:27 GMT
From: "Peter R. Ham" <ptolemy!eos!shelby!neon!neon.Stanford.EDU!ham@ames.arc.nasa.gov>
To: scheme@mc.lcs.mit.edu
Subject: calling C++ from C,Scheme,Lisp and other languages
I'm writing a large application in C++. It includes Scheme as
the extension language, so Scheme needs to be able to call C++.
This problem is not really Scheme specific. Calling C++ from
other languages like C and Lisp should present similar problems.
Let's say that I write a C function called, "call_c++()", the arguments
of the function are:
1) the (un qualified ) name of the C++ member function, assume in
character string form for now
2) a pointer to the object that the member function will be invoked on
3) a variable length list of pointers to the C++ objects that are the arguments
that the member function will be invoked withto the arguments that
The operations that "call_c++" needs to perform are:
1) map the function name and the class of the "receiving" object to
the address of the member function to be called
2) adjust the "this" pointer of the "receiving object" to match the structure
layout expected by the member function
3) adjust the "this" pointers of the argument objects to match the structure
layouts expected by the member function
The problem:
The function "call_c++" needs access to type (or class) information about
objects at run time. (I realize that Mark Linton wrote a paper on this,
but I haven't got a copy yet. )
Some of this type information is available in an object's virtual function
table. I'm still pretty confuse about how virtual function tables are
layed out, especially with multiple inheritance. Can anyone suggest a
reference on this? Is this area too compiler specific to design a scheme
that works across C++ implementations?
Can anyone think of a clever way to coax the C++ compiler to spit out
the information I need other than virtual function tables? I think I need
more information than the vtable will provide.
Specifically, is there a way to determine an objects class at run time.
As I understand it, inside a C++ object is contained a pointer to its
virtual function table, no? Is this effectively it's type? It seems that
there should be only one vtable per class, but these might be duplicated
due to the C++ compilation and linking process, no? Is there a way
to ensure that only one vtable per class is produced? This might be considered
a linking problem, but I want to have some kind of class identifier and
multiple (but identical) vtables would foil this scheme.
One idea I have is to hack g++'s front end in order to generate portions
of my "call_c++" function automatically. I'm not sure how hard this would
be, but might go a long way towards automating this inter-language function
calling mechanism. I could get the front end to print out
1) a description of the c++ class hiearchy
2) the sizes of class structures
3) a mapping from classes and member function names to the member function
addresses
4) descriptions of the types of the arguments of member functions
5) descriptions of how to cast one C++ class object to a super class or
sub class object
I'd appreciate any references or suggestions.
--
Peter Ham PO Box 3430 (h)(415) 322-4390
MS Computer Science Student Stanford, CA ham@cs.stanford.edu
Stanford University 94309 (o)(415) 723-2067
------------------------------
End of Scheme Digest
********************
∂10-Jun-90 2344 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #393
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 10 Jun 90 23:44:04 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA18198; Mon, 11 Jun 90 02:43:11 EDT
Received: from lcs.mit.edu (mc.lcs.mit.edu) by zurich.ai.mit.edu; Mon, 11 Jun 90 02:40:43 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa01216;
11 Jun 90 2:40 EDT
Message-Id: <DIGEST.184.900611.024028.69@MC.LCS.MIT.EDU>
Date: 11 Jun 90 02:40:28 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #393
Scheme Digest #393 11 Jun 90 02:40:28 EDT
Today's Topics:
Threaded interpreters for Lisp or Scheme?
problems with PC scheme, VM error, etc.
----------------------------------------------------------------------
Message-ID: <136989@sun.Eng.Sun.COM>
Date: 10 Jun 90 21:34:06 GMT
From: "Vladimir G. Ivanovic" <prosper@sun.com>
To: scheme@mc.lcs.mit.edu
Subject: Threaded interpreters for Lisp or Scheme?
In v25 #2 of SIGPLAN Notices (February 1990), David J. Nordstrom of DePaul
University contributed an article called "Threading Lisp." From the
introduction:
This article describes a simple method of implementing a threaded
interpreter (TI) for Lisp. TIs are fast, space-efficient, flexible, readily
extensible, and easy to implement since much (or most) of the interpreter can
be written in the language implemented by the interpreter.
Can anyone point me to an implementation of a TI for Lisp or Scheme? The ideal
would be a version in C for SPARCstations running SunOS 4.0.3c (but that's
asking for a lot!) Any help would be greatly appreciated.
I'll summarize for the net's benefit.
-- Vladimir
Vladimir G. Ivanovic vladimir@sun.com
M/S MTV12-33 vivanovic@sun.com
Sun Microsystems, Inc.
2550 Garcia Ave.
Mountain View, CA 94043-1100 (415) 336-2315
--
Vladimir G. Ivanovic vladimir@sun.com
M/S 12-33 vladimir@prosper.ebb.eng.sun.com
Sun Microsystems, Inc. vivanovic@sun.com
------------------------------
Message-ID: <9006110337.AA28269@mailhost.samsung.com>
Date: Sun, 10 Jun 90 17:58:58 EDT
From: gjc@mitech.com
Reply-To: gjc@mitech.com
To: scheme@mc.lcs.mit.edu
Subject: problems with PC scheme, VM error, etc.
Software problems of an extremely random nature could very well
be do to corruption of data due to memory or disk problems.
Try things in a fresh environment (from known good distribution
media) on a different machine.
------------------------------
End of Scheme Digest
********************
∂12-Jun-90 0001 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #394
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 12 Jun 90 00:01:23 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA07373; Tue, 12 Jun 90 02:59:32 EDT
Received: from lcs.mit.edu (mintaka.lcs.mit.edu) by zurich.ai.mit.edu; Tue, 12 Jun 90 02:57:01 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa29061;
12 Jun 90 2:42 EDT
Message-Id: <DIGEST.184.900612.022528.73@MC.LCS.MIT.EDU>
Date: 12 Jun 90 02:25:28 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #394
Scheme Digest #394 12 Jun 90 02:25:28 EDT
Today's Topics:
Scheme for the DEC 3100 (2 messages)
SUMMARY--reindentation and pretty-printing for Scheme (2 messages)
----------------------------------------------------------------------
Message-ID: <TALVOLA.90Jun11134144@janus.berkeley.edu>
Date: 11 Jun 90 20:41:44 GMT
From: Erik Talvola <snorkelwacker!apple!agate!agate!talvola@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Scheme for the DEC 3100
Can anyone tell me what Scheme's are available for the DEC 3100?
Cadence said last winter that they would have Chez Scheme out sometime
in the summer, and I think I read that C-Scheme is out.
Also, does anyone have an e-mail address for Cadence? Thanks in
advance...
--
+----------------------------+
! Erik Talvola | "It's just what we need... a colossal negative
! talvola@janus.berkeley.edu | space wedgie of great power coming right at us
! ...!ucbvax!janus!talvola | at warp speed." -- Star Drek
------------------------------
Message-ID: <8209@ubc-cs.UUCP>
Date: 12 Jun 90 00:44:01 GMT
From: Vincent Manis <van-bc!ubc-cs!manis@uunet.uu.net>
To: scheme@mc.lcs.mit.edu
Subject: Re: Scheme for the DEC 3100
We were looking at buying DECStation 3100's for our new first year lab.
Cadence said that they were committed to delivering a 3100
implementation, and that they expected it to be ready in July.
In the event, we bought NeXTs instead. We're using a pre-release version
of Chez Scheme.
--
\ Vincent Manis <manis@cs.ubc.ca> "There is no law that vulgarity and
\ Department of Computer Science literary excellence cannot coexist."
/\ University of British Columbia -- A. Trevor Hodge
/ \ Vancouver, BC, Canada V6T 1W5 (604) 228-2394
------------------------------
Message-ID: <1990Jun11.175522.27556@sq.sq.com>
Date: 11 Jun 90 17:55:22 GMT
From: David A Keldsen <snorkelwacker!usc!cs.utexas.edu!news-server.csri.toronto.edu!utgpu!utzoo!sq!dak@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: SUMMARY--reindentation and pretty-printing for Scheme
OK, here's the promised summary. Thanks to all the folks who replied
(quickly, too!).
Fast overview:
Emacs and vi can re-indent; emacs can do it in batch mode; fools lisp
has pretty-printing code. A standalone re-indenter in C by
wri!henry@uunet.uu.net is posted as a follow-up to this posting, in
comp.lang.scheme only.
Detailed summary:
John R. Ellis (ellis@src.dec.com) points out that my initial request is
ambiguous. Pretty-printers and a re-indenters are quite different
beasts. A *pretty printer* is either a print procedure for an internal
form, or is a code reformatter that is permitted to re-arrange the
code. A *re-indenter* merely re-adjusts the indentation, and is not
permitted to change the line splits.
mob@media-lab.media.mit.edu, alms@cambridge.apple.com (Andrew L. M. Shalit),
ted@NMSU.Edu, rees@parc.xerox.com, vladimir@Eng.Sun.COM (Vladimir G. Ivanovic)
and Keiji Kanazawa <kgk@cs.brown.edu> all suggested Emacs.
(This was before my revised specification that the code be free of
encumbrances, small, and portable). For those free of these
specifications, it was also noted that GNU emacs can be fired up in
batch mode, for use as a stand-alone indenter.
Tim Bradshaw <tim@cstr.edinburgh.ac.uk> offered the suggestion that in
Common Lisp, it is easy to redefine the read table to keep comments (as
asked in my second request). This isn't in the standard for Scheme,
but it is supported in some implementations. donc@vaxa.isi.edu (Don
Cohen) also suggested the readtable solution.
J. A. Durieux <xerox@cs.vu.nl> and Jeff Mantei <uiucdcs!cs.uiuc.edu!mantei>
both pointed out that vi has a lisp mode (:set lisp), and that =<addr>
will lisp-indent the specified lines. =% was suggested as being
especially useful; it re-indents to the matching parenthesis. (Note
also that vi will start up in lisp mode, with auto-indent set, and
show-matching-parentheses, if you use the -l option).
Ozan Yigit <oz@nexus.yorku.ca> noted that the fools lisp distribution
by Jonathan Lee (jonathan@scam.berkeley.edu) contains some nice
pretty-printing code.
And finally, wri!henry@uunet.uu.net sent the stand-alone re-indentation
code, which I am posting as a follow-up to this article, in
comp.lang.scheme only.
--
// David A. 'Dak' Keldsen: dak@sq.com or utai[.toronto.edu]!sq!dak
// "I have heard the mermaids singing, each to each." -- T.S.Eliot
------------------------------
Message-ID: <1990Jun11.181710.27797@sq.sq.com>
Date: 11 Jun 90 18:17:10 GMT
From: David A Keldsen <snorkelwacker!usc!cs.utexas.edu!news-server.csri.toronto.edu!utgpu!utzoo!sq!dak@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: SUMMARY--reindentation and pretty-printing for Scheme
And here's the promised stand-alone indenter (in C).
---------------------------------------------------------------------
From: wri!henry@uunet.uu.net
Received: by WRI.com (3.2/SMI-3.0DEV3)
id AA28825; Fri, 8 Jun 90 18:19:25 CDT
Message-Id: <9006082319.AA28825@WRI.com>
Date: Fri, 8 Jun 90 19:19:24 EDT
To: dak@sq.com
Here is a very simple indenter that I use all the time. Note, it doesn't
pretty print, just indent. I find that that is exactly what I want.
/*
* Indent a lisp (scheme) program.
* The only transformations performed are:
* Leading white space is replaced with 4 n spaces where n is the
* nesting level.
* Open and close square brackets (``['' and ``]'') are paired together
* and the latter are replaced with the correct number of close
* parens (``)'').
*/
#include <stdio.h>
#include <assert.h>
/*
* The following definitions make C more amenable to a purist.
*/
#define bool char /* boolean type */
#define uint unsigned int /* short names for unsigned types */
#define ulong unsigned long
#define uchar unsigned char
#define ushort unsigned short int
#define not ! /* logical negation operator */
#define and && /* logical conjunction */
#define or || /* logical disjunction */
#define TRUE (0 == 0)
#define FALSE (not TRUE)
#define loop while (TRUE) /* loop until break */
#define EOS '\0' /* end-of-string char */
#define NULL 0 /* invalid pointer */
#define cardof(a) (sizeof(a) / sizeof(*(a)))
#define endof(a) ((a) + cardof(a))
#define bitsof(a) (sizeof(a) * 8)
/*
* Function declarations that should be in stdio.h.
*/
extern char *malloc(),
*realloc();
#define ISPACE 4 /* distance to indent for each level */
#define TAB 8 /* distance between tab stops */
#define MAXSQ 32 /* maximum nesting of ``['' and ``]'' */
/*
* Note, an entry in sqs records the level BEFORE the cooresponding ``[''
* was seen.
*/
static int level, /* current ``('' level */
sqs[MAXSQ], /* stack of un-matched ``['' */
*sqtop = sqs - 1; /* top of sqs stack */
extern int main();
static void die(),
scan(),
doline(),
docomment(),
dostring();
static int doocto();
static void uplevel(),
downlevel();
static int skipws();
static void putws();
int
main()
{
scan();
return (0);
}
static void
die(fmt, arg)
char *fmt;
int arg;
{
fflush(stdout);
fprintf(stderr, fmt, arg);
fprintf(stderr, "\n");
exit(1);
}
static void
scan()
{
int ch;
loop
switch (ch = skipws()) {
case '\n':
putchar('\n');
continue;
case EOF:
if (level != 0)
die("%d missing ``)''.", level);
return;
default:
putws(ISPACE * level);
doline(ch);
putchar('\n');
}
}
static void
doline(ch)
int ch;
{
loop {
switch (ch) {
case '(':
uplevel(ch);
break;
case ')':
downlevel(ch);
break;
case '[':
uplevel(ch);
ch = '(';
break;
case ']':
downlevel(ch);
ch = ')';
break;
case ';':
docomment(ch);
return;
case '"':
dostring(ch);
ch = getchar();
continue;
case '#':
ch = doocto(ch);
continue;
case '\n':
case EOF:
return;
}
putchar(ch);
ch = getchar();
}
}
static void
docomment(ch)
int ch;
{
assert(ch == ';');
do {
putchar(ch);
ch = getchar();
} while (ch != '\n' && ch != EOF);
}
static void
dostring(ch)
int ch;
{
static bool warned = FALSE;
assert(ch == '\"');
loop {
putchar(ch);
ch = getchar();
switch (ch) {
case EOF:
putchar('\n');
die("Unterminated string");
case '\n':
if (not warned) {
warned = TRUE;
fprintf(stderr,
"Warning: new-line in string\n");
}
break;
case '"':
putchar(ch);
return;
case '\\':
putchar(ch);
ch = getchar();
if (ch == EOF) {
putchar('\n');
die("Unterminted string");
}
break;
}
}
}
static int
doocto(ch)
int ch;
{
assert(ch == '#');
putchar(ch);
ch = getchar();
switch (ch) {
case '\\':
putchar(ch);
ch = getchar();
if (ch == EOF) {
putchar('\n');
die("Unterminated character constant");
}
putchar(ch);
return (getchar());
default:
return (ch);
}
}
static void
uplevel(ch)
int ch;
{
switch (ch) {
case '(':
++level;
break;
case '[':
if (++sqtop == endof(sqs)) {
putchar('\n');
die("[ ... ] too deeply nested");
}
*sqtop = level++;
break;
default:
assert(FALSE);
}
}
static void
downlevel(ch)
int ch;
{
switch (ch) {
case ')':
--level;
if ((sqtop >= sqs)
and (level <= *sqtop)) {
putchar('\n');
die("Unmatched ``[''.");
}
if (level < 0) {
putchar('\n');
die("Too many ``)''.");
}
break;
case ']':
if (sqtop < sqs) {
putchar('\n');
die("Too many ``]''.");
}
assert(*sqtop >= 0);
if (--level != *sqtop) {
assert(level >= *sqtop);
putchar('\n');
die("``]'' seen but need %d ``)'' first",
level - *sqtop);
}
--sqtop;
break;
default:
assert(FALSE);
}
}
static int
skipws()
{
int ch;
loop
switch (ch = getchar()) {
case ' ':
case '\t':
break;
default:
return (ch);
}
}
static void
putws(len)
int len;
{
assert(len >= 0);
for (; len >= TAB; len -= TAB)
putchar('\t');
for (; len != 0; --len)
putchar(' ');
}
--
// David A. 'Dak' Keldsen: dak@sq.com or utai[.toronto.edu]!sq!dak
// "I have heard the mermaids singing, each to each." -- T.S.Eliot
------------------------------
End of Scheme Digest
********************
∂12-Jun-90 2359 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #395
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 12 Jun 90 23:59:52 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA24370; Wed, 13 Jun 90 02:53:46 EDT
Received: from lcs.mit.edu (mintaka.lcs.mit.edu) by zurich.ai.mit.edu; Wed, 13 Jun 90 02:51:18 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa26068;
13 Jun 90 2:30 EDT
Message-Id: <DIGEST.184.900613.021029.80@MC.LCS.MIT.EDU>
Date: 13 Jun 90 02:10:28 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #395
Scheme Digest #395 13 Jun 90 02:10:28 EDT
Today's Topics:
Scheme for Decstation 3100
Scheme for the DECstation 3100
address of MacScheme makers?
Scheme for the DEC 3100
----------------------------------------------------------------------
Message-ID: <9006120827.AA20115@bronto.soar.cs.cmu.edu>
Date: Tue, 12 Jun 90 04:27:42 EDT
From: Olin Shivers <shivers@bronto.soar.cs.cmu.edu>
To: Scheme@MINTAKA.lcs.mit.edu
Subject: Scheme for Decstation 3100
T has been running on the Pmax for quite a while. My officemate does
circuit simulation research on his with it, and seems fairly happy.
You can ftp it from MIT.
-Olin
------------------------------
Message-ID: <9006121653.AA16536@jove.pa.dec.com>
Date: Tue, 12 Jun 90 09:53:15 PDT
From: bartlett@wrl.dec.com
To: Scheme@lcs.mit.edu
CC: bartlett@wrl.dec.com
Subject: Re: Scheme for the DECstation 3100
Another Scheme for the DECstation 3100 is Scheme->C. The system is
available for anonymous ftp from 'gatekeeper.dec.com' [16.1.0.2]. The
Scheme->C files are in '/pub/DEC/Scheme-to-C'. Those files include:
README - overview and copyright notice.
23feb90.tar.Z - compressed tar file containing all source
and documentation.
Joel Bartlett bartlett@decwrl.dec.com
------------------------------
Message-ID: <1990Jun12.183044.25836@cec1.wustl.edu>
Date: 12 Jun 90 18:30:44 GMT
From: "David D. Jensen" <snorkelwacker!usc!cs.utexas.edu!uwm.edu!ux1.cso.uiuc.edu!brutus.cs.uiuc.edu!wuarchive!cec2!news@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: address of MacScheme makers?
Could someone mail me the NEW address of the makers of MacScheme?
A few weeks ago, someone said that the company has changed their name
and moved. I didn't think I would need the information, now I do.
All I have is: Semantic Microsystems in Beaverton Oregon. Thanks.
------------------------------
Message-ID: <22168@boulder.Colorado.EDU>
Date: 12 Jun 90 20:01:45 GMT
From: Dirk Grunwald <grunwald@boulder.colorado.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: Scheme for the DEC 3100
You can get the Scheme->C compiler from gatekeeper.dec.com:pub/DEC.
This translates Scheme to C & the compiles that. Or, you can use the
'sci' interpreter.
I haven't used this for big applications, but they're fairly nice
Scheme environments for UNIX. You get a great UNIX interface, and
there's a libX interface as well. There's also SCIX, a native scheme
interface using an object-oriented macro package & an object-oriented
representation of X.
------------------------------
End of Scheme Digest
********************
∂14-Jun-90 0042 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #396
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 14 Jun 90 00:42:27 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA12979; Thu, 14 Jun 90 03:38:56 EDT
Received: from lcs.mit.edu (mintaka.lcs.mit.edu) by zurich.ai.mit.edu; Thu, 14 Jun 90 03:36:31 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22667;
14 Jun 90 3:26 EDT
Message-Id: <DIGEST.184.900614.031029.86@MC.LCS.MIT.EDU>
Date: 14 Jun 90 03:10:29 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #396
Scheme Digest #396 14 Jun 90 03:10:29 EDT
Today's Topics:
interface/graphics development environments for 386/RS6000 (2 messages)
interface development environments for 386/RS6000
Call for Papers
----------------------------------------------------------------------
Message-ID: <835@anaxagoras.ils.nwu.edu>
Date: 13 Jun 90 15:40:27 GMT
From: Charles Earl <snorkelwacker!apple!usc!cs.utexas.edu!mailrus!accuvax.nwu.edu!anaxagoras!aristotle.ils.nwu.edu!cearl@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: interface/graphics development environments for 386/RS6000
We will be developing multimedia (e.g. video, animation, digitized images,etc.)
based educational software using ibm RS/6000s and 386's as development
platforms -- assume UNIX environment. Initial development will most likely
occur on the RISC machines but
the 386's are intended target (we will actually be using 386s for some months
until RISCs arrive).
We have been a MacII shop, doing most development in Mac Common Lisp.
I am trying to decide on an appropriate development environment and
would like feedback from the experts. We would like to use
Lisp/Scheme, but Smalltalk, C++, C, etc. would be ok if no other
options for graphics environments exist.
The environment should:
(1) Facillitate construction of window-based applications. This also
implies support of important window env features like buttons,
icons, etc.
(2) Support development of fast, attractive animation -- that is,
we would want fairly rich graphics libraries/packages.
(3) Allow development of multimedia applications, especially those
which would incorporate video.
(4) Have a foreign function facility (e.g. would allow calls to Pascal,
C, etc.).
(5) Provide support of object - oriented programming (this is not
essential ).
Any ideas, comments appreciated
------------------------------
Message-ID: <840@anaxagoras.ils.nwu.edu>
Date: 13 Jun 90 17:22:52 GMT
From: Charles Earl <cs.utexas.edu!mailrus!accuvax.nwu.edu!anaxagoras!aristotle.ils.nwu.edu!cearl@yale-zoo.arpa>
To: scheme@mc.lcs.mit.edu
Subject: interface development environments for 386/RS6000
We will be developing multimedia (e.g. video, animation, digitized images,etc.)
based educational software using ibm RS/6000s and 386's as development
platforms. Initial development will most likely occur on the RISC machines but
the 386's are intended target (we will actually be using 386s for some months
until RISCs arrive).
We have been a MacII shop, doing most development in Mac Common Lisp.
I am trying to decide on an appropriate development environment and
would like feedback from the experts. We would like to use
Lisp/Scheme, but Smalltalk, C++, C, etc. would be ok if no other
options for graphics environments exist.
The environment should:
(1) Facillitate construction of window-based applications. This also
implies support of important window env features like buttons,
icons, etc.
(2) Support development of fast, attractive animation -- that is,
we would want fairly rich graphics libraries/packages.
(3) Allow development of multimedia applications, especially those
which would incorporate video.
(4) Have a foreign function facility (e.g. would allow calls to Pascal,
C, etc.).
(5) Provide support of object - oriented programming (this is not
essential ).
Any ideas, comments appreciated
------------------------------
Message-ID: <41909@apple.Apple.COM>
Date: 13 Jun 90 18:14:25 GMT
From: Chuck Lins <snorkelwacker!apple!lins@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Call for Papers
Announcement and Call for Papers
-------------------------------
Aims and Scope:
The international journal "Structured Programming" serves the professional
computing and engineering community. It includes technical contributions
and short communications in the area of
o programming
o programming methodology and style
o programming languages
o programming environments
o compilers
o interpreters
o applications
The journal reports on technical advances in the field, announce and review
systems, implementations, and relevant publications. "Structured Programming"
emphasizes innovative concepts in programming (such as literate programming)
and practical solutions for real problems. "Structured Programming" is not
intended to be an archival journal, but instead, an informal forum for the
timely exchange of ideas and information.
Readership:
computer scientists and engineers, software developers
Call For Papers:
The journal encourages contributions of original papers on any aspect of
programming methodology and style, programming languages, programming
environments, compilers, interpreters and applications. All papers will be
reviewed. For papers of high quality, the journal can offer timely publication.
Papers should be submitted to:
Prof. Dr. Gustav Pomberger
Johannes Kepler University of Linz
A-4040 Linz
Austria
Tel.: +43-732-2468-683
Fax: 732-2468-10
E-Mail: K2G0190@AEARN.BITNET
or to
Springer-Verlag
815 De La Vina Street
Santa Barbara, CA 93101
USA
Tel.: (805) 963-7960
Fax: (805) 966-3491
E-Mail: rossbach@hub.ucsb.edu
--
Chuck Lins | "Is this the kind of work you'd like to do?"
Apple Computer, Inc. | -- Front 242
20525 Mariani Avenue | Internet: lins@apple.com
Mail Stop 37-BD | AppleLink: LINS@applelink.apple.com
Cupertino, CA 95014 | "Self-proclaimed Object Oberon Evangelist"
The intersection of Apple's ideas and my ideas yields the empty set.
------------------------------
Message-ID: <8167@uhccux.uhcc.Hawaii.Edu>
Date: 13 Jun 90 19:31:08 GMT
From: John Dunn <munnari.oz.au!uhccux!dunn@uunet.uu.net>
To: scheme@mc.lcs.mit.edu
Subject: Re: interface/graphics development environments for 386/RS6000
In article <835@anaxagoras.ils.nwu.edu> cearl@aristotle.ils.nwu.edu (Charles Earl) writes:
>We will be developing multimedia (e.g. video, animation, digitized images,etc.)
>based educational software using ibm RS/6000s and 386's as development
>platforms -- assume UNIX environment. Initial development will most likely
> occur on the RISC machines but
>the 386's are intended target (we will actually be using 386s for some months
>until RISCs arrive).
>
>We have been a MacII shop, doing most development in Mac Common Lisp.
>I am trying to decide on an appropriate development environment and
>would like feedback from the experts. We would like to use
>Lisp/Scheme, but Smalltalk, C++, C, etc. would be ok if no other
>options for graphics environments exist.
>
If you are most comfortable working in an interactive Lisp environment,
but you need to produce real-world working code, you might consider
Laboratory Microsystem's 386/UR Forth. It runs in protected mode,
has a first rate virtual memory facility, and is faster then C by
a fair degree. Several times I have gone to assembley language for
loop-critical components, only to find I had a 2* savings - the speed
of this product is difficult to believe. Compile speed is likewise
considerably faster than you are likely to see with C or Pascal -
especially when you include link time.
I believe LMI has a compatible version that works under UNIX. They
definitely have one that works under OS/2, and have made noises about
bringing out a Windows 3 version.
My own experience was similar to yours - I had worked in a Lisp
developemt mode until there was enough groundwork to take the project
to a real-world releasable version. After close to 6 months of false
starts, I tried out 386 UR/Forth. The only thing that wasn't available
was some means of treating data as objects - I had become use to
Flavors in Lisp. Eventually, after an exaustive search of the available
Forth code (there is a mountain of it, but it is mostly unusable IMHO),
I gave up, bit the bullet and wrote a object-type memory manager
with very fast automatic garbage collection. This whole system has
worked so well for me that now, even if there were to be a Lisp
package around that included a reasonable means of delivering the
finished software to the end user, I would stick with 386 Forth.
Oh yes, the Memory Object Package is in the Public Domain - You will
find it on the UR/Forth BBS system that you will have access to when
you buy any of the UR/Forths.
-John Dunn
------------------------------
End of Scheme Digest
********************
∂15-Jun-90 0037 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #397
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 15 Jun 90 00:36:55 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA00555; Fri, 15 Jun 90 03:33:25 EDT
Received: from lcs.mit.edu (mintaka.lcs.mit.edu) by zurich.ai.mit.edu; Fri, 15 Jun 90 03:30:58 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa20254;
15 Jun 90 3:23 EDT
Message-Id: <DIGEST.184.900615.025530.94@MC.LCS.MIT.EDU>
Date: 15 Jun 90 02:55:30 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #397
Scheme Digest #397 15 Jun 90 02:55:30 EDT
Today's Topics:
first-year programming language
Scheme Digest #396
xscheme: has anybody a more recent version than 0.16
----------------------------------------------------------------------
Message-ID: <3256@goanna.cs.rmit.oz.au>
Date: 14 Jun 90 10:39:08 GMT
From: "Richard A. O'Keefe" <snorkelwacker!usc!samsung!munnari.oz.au!goanna!ok@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: first-year programming language
Currently, the CS department of RMIT uses Pascal in the first year.
But I'm afraid It Simply Won't _Do_ any more to use a language which
in its standard form goes out of its way to make software reuse hard.
So we're thinking about alternatives for next year. My current
feeling is that a combination of (ANSI) C and (draft standard) Scheme
may be appropriate.
Criteria.
--------
1. We must be able to get our hands on affordable implementations of
the language or languages that are really *solid*. Beginning
students have enough trouble finding and coping with their own
mistakes. I'll take quiet reliability with minimal features over
sexy-but-shoddy any day. It's *immoral* to foist flaky systems
onto beginners.
2. The affordable reliable implementations we need are for
PCs
Macs
Encore Multimax (NS32532, UNIX System V.3)
3. *Reliable* support/debugging tools would be a big plus. (GNU
Emacs provides some very nice interfaces, but can you really
see a couple of hundred students using it _at_once_ on a time-
shared multiprocessor?) There are some very nice things on
Macs and PCs, but the Pascal debugger we currently have on the
Encore, um, well, let's just say it wouldn't win any awards.
4. There should already be experience with using the language as a
first language that we can draw on. Ideally there would be some
good textbooks. There might even be people will to tell us what
works in such a course and what doesn't.
5. Most RMIT CS students look for a job once they have their degree.
That means that as well as teaching the fundamentals of computer
science, we have to teach them skills which they _can_tell_ are
going to be relevant to getting jobs. So although there are a
lot of really neat things we could use in 1st year we can't ONLY
use something ideologically sound.
6. But even the "practical" language should at the very least not
get in the way of good software engineering practice. At an
absolute minimum, it should be _possible_ to put programs
together out of lots of little pieces without departing from
the "official" version of the language. (Fortran is in, old
ISO Pascal is out.) Some kind of "official" support for
assertion checking (best debugging tool I know) would be good.
7. On the other hand, disc space is limited on our file servers &c
(isn't it always) so something that requires large per-user
states (such as __poor__ implementations of Ada) is out.
8. We're serious about databases here. There should be data base
products around offering embedded SQL for language X.
Comments
========
If there are *solid* Ada implementations that we can afford to get and
use, I'd argue for Ada. The language has all the things which looked
good about Pascal, with few of the hidden "gotcha's". (I very much
like the fact that integer overflow &c is by default _reported_.)
I know that the University of Bristol use Modula-2 plus a functional
language (I think Miranda). However, the teachers I spoke to there
complained of the quality of the Modula-2 compiler available on their
UNIX system. As an advance on Pascal, Modula-2 strikes me as "too
little, too late", and whatever its merits, it doesn't look as good
on a resume' as something the employer is actually using. The point
does remain that people I trust tell me they are getting good results
from this mix.
Old ISO Pascal has its limits. I understand that there is a new
standard, "Pascal Extended" or some such. This may well answer most
of the objections to the language qua language. But what about
*solid* implementations available *now*?
Eiffel? (Pauses to wipe chin.) (Does it again.) We have Eiffel on
a non-teaching machine and are in the process of getting it for our
Encores. I can hardly _wait_. But PC? Mac? How does it work as
a first language? Is Eiffel conquering the world at the rate it
deserves, so that students starting next year are going to find
employers wanting their skills in 3 or 4 years' time? (Yes, I _know_
that our students will end up being able to learn other languages.
They're going to be exposed to several others here. But their future
employers have their own points of view.)
As far as I can see, there isn't _anything_ students do in the 1st or
2nd years here that can't be done more easily in Scheme. We have a copy
of T 3.1 already running (T has a Scheme environment). It is _so_ nice
to be able to say to a student who is wondering how some algorithm works
"let's type that up in Scheme <tappity tap> now let's run it, let's trace
that, let's stop and pick up a copy of that data structure and poke around
in it, let's print out that other thing" all within the one language.
(Why don't more languages provide ways of producing human-readable
representations of data structures automatically? And of reading them
back?) Time after time something which takes a few lines of Scheme takes
5 or 8 times as many lines in Pascal (ignoring begins and ends) and
(we haven't got a particularly good Pascal compiler) doesn't run any faster.
I really hate to say this, because giving beginners this much rope does
_not_ commend itself to me, but ANSI C
1 has some solid implementations (well, at least as solid as Pascal)
2 on PCs, Macs, and I think gcc will run on Encores (I don't agree
with the FSF, but gcc is commercial quality or better)
3 Some of the PC and Mac versions have flashy environments,
and gdb _has_ to be an improvement on the Encore Pascal debugger
4 C has been around a while, there are lots of books, including
some nice data structures books (and the University just up the
road use C, and we're teaching it in a later year _anyway_)
5 C is a definite plus on a resume'
6 Building C programs out of pieces is not only possible, it's
the norm. <assert.h> is pretty minimal, but it's _there_.
'make' or tools like it is available for PCs and so on, and even
if it weren't, Melbourne University have a super-smart make called
'cake' that we can pick up. And we have 'mkmf' so making makefiles
isn't much of a chore either.
7 C implementations don't require special "project" directories,
and write permission on the main library area isn't needed.
8 This one pretty well forces the choice of C, but it isn't as
important as the others.
There are of course all the well known traps and pitfalls of C, but Pascal
has a few of its own which aren't quite so well known. I have thought about
C++, but that is a very complex language and it keeps changing. It meets
many of the criteria. (Judging from comp.lang.c++, *solid* implementations
are rare because no-one quite knows what they should do...) However, switching
from ANSI C to C++ ought to be fairly painless.
Why do I think that it would be a good idea to teach Scheme as well?
Because it is simpler and more expressive than Pascal or C, and the
contrast should be illuminating. For example, instead of thinking of
static types and static type declarations as Part Of The Way Things
Just Have To Be, students would immediately realise that they are a
_choice_ in a language; a few mistakes in Scheme will show _why_ static
types in C are useful, a little serious programming (trying to write a
generic table lookup function, say) will show why oversimplistic types
(as in C) are a pain. The fact that most data structures can be written
out readably and read back is a big win. The entire absence of malloc()
and free() in Scheme is a *huge* advantage.
Why Scheme rather than some other Lisp dialect or functional language?
Because it is a _small_ language for which good implementations are
available on PCs, Macs, and Encores.
Ok, so why am I posting this?
To pick your brains, of course.
If you have taught a first-year CS course successfully using one of
these languages, I'd like to hear about why you made that choice, why
it worked (or why it didn't), why you think my leaning towards ANSI C
and Scheme is inspired/utterly stupid.
Am i using the right criteria? What _should_ I be looking for?
Please send E-mail to
ok@goanna.cs.rmit.oz.au
with "first year" as the subject line. I'll summarise.
--
"A 7th class of programs, correct in every way, is believed to exist by a
few computer scientists. However, no example could be found to include here."
------------------------------
Message-ID: <20061409533609@vms.macc.wisc.edu>
Date: Thu, 14 Jun 90 09:53 CDT
From: BILL GROGAN <WGROGAN@vms.macc.wisc.edu>
To: Scheme@lcs.mit.edu
Subject: Re: Scheme Digest #396
Re: Interface development for 386/RS6000
I have just received Borland's C++ package. It's out of the wrapper but I'm
still reading the 2 feet of books that came with it. The advantage of this
package is the ability to link to other languages, esp. Borland's family of
Pascal, Pascal 5.5 - object oriented Pascal, Assembler, Debugger and Profiler,
as well as Borland's Prolog (assuming I can find my disks for this). The
problem with C and C++ is library compatibilty. This is worth looking into for
the 386 platform. I am just learning about various linkers and other libraries
that can be used with this development system so I can not yet answer to UNIX
compatabilty. I'm trying to work with the protected mode in the 386 and hope
that this C++ system will let me. The product is suppose to be a full AT&T
version 2 implementation of C++ as well as meeting the X3J11 ANSI C standard.
It might take me some time to decide if this is the way to go in the area of
development. There does seem to be a good collection of graphic routines that
are included. Can any one point me to a good 32 bit assembler and definitive
books on 386 architecture?
Bill Grogan
WGROGAN@VMS.MACC.WISC.EDU
( C++ ,use the value and increment afterwards, does use preceed development? )
:)-/-<
------------------------------
Message-ID: <8097@mirsa.inria.fr>
Date: 14 Jun 90 15:48:40 GMT
From: Colas Nahaboo <mcsun!inria!mirsa!avahi.inria.fr!colas@uunet.uu.net>
To: scheme@mc.lcs.mit.edu
Subject: xscheme: has anybody a more recent version than 0.16
I got xscheme from terminator.cc.umich.edu, but is is version 0.16 (jan 9 1989)
Does anybody has a more recent version?
(I can use ftp)
Colas Nahaboo, Bull Research France -- Koala Project -- GWM X11 Window Manager
colas@avahi.inria.fr Phone: (33) 93.65.77.70, Fax: (33) 93 65 77 66
INRIA - Sophia Antipolis, 2004, rte des Lucioles, 06565 Valbonne Cedex, FRANCE
------------------------------
End of Scheme Digest
********************
∂16-Jun-90 0037 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #398
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 16 Jun 90 00:37:42 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA06508; Sat, 16 Jun 90 03:37:17 EDT
Received: from lcs.mit.edu (mintaka.lcs.mit.edu) by zurich.ai.mit.edu; Sat, 16 Jun 90 03:34:49 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22321;
16 Jun 90 3:29 EDT
Message-Id: <DIGEST.184.900616.032732.1@MC.LCS.MIT.EDU>
Date: 16 Jun 90 03:27:32 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #398
Scheme Digest #398 16 Jun 90 03:27:32 EDT
Today's Topics:
Is the R4 report out yet?
interface/graphics development environments for 386/RS6000
T3.1 for the nExt Silly Named Computer.
----------------------------------------------------------------------
Message-ID: <577@argosy.UUCP>
Date: 13 Jun 90 20:59:06 GMT
From: "Jay R. Freeman" <argosy!freeman@decwrl.dec.com>
To: scheme@mc.lcs.mit.edu
Subject: Is the R4 report out yet?
A bibilography in a recent SigPLAN notices suggests that the R4 report
has been published. Is that so? Can someone tell me how to obtain a
copy (where to write and how much it costs)?
Thanks.
-- Jay Freeman
<canonical disclaimer -- opinions herein are my own>
------------------------------
Message-ID: <1990Jun15.071605.12274@actrix.co.nz>
Date: 15 Jun 90 07:16:05 GMT
From: Paul Gillingwater <snorkelwacker!usc!samsung!munnari.oz.au!comp.vuw.ac.nz!dsiramd!actrix!paul@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: interface/graphics development environments for 386/RS6000
In article <835@anaxagoras.ils.nwu.edu> cearl@aristotle.ils.nwu.edu (Charles Earl) writes:
Try XVT, from XVT software in Boulder, Colorado. It's a virtual toolkit
with heaps of features, that runs on a wide range of UNIX and other
platforms. I think there is a Macintosh version too, and even one
for DOS! It's far more than just a set of Motif widgets, although
it's compatible with them.
> (1) Facillitate construction of window-based applications. This also
> implies support of important window env features like buttons,
> icons, etc.
Yep, does all this I think.
> (2) Support development of fast, attractive animation -- that is,
> we would want fairly rich graphics libraries/packages.
Don't know -- this might be a weak area.
> (3) Allow development of multimedia applications, especially those
> which would incorporate video.
Don't know.
> (4) Have a foreign function facility (e.g. would allow calls to Pascal,
> C, etc.).
Yes, I think so.
> (5) Provide support of object - oriented programming (this is not
> essential ).
There's a library for C++ use.
Hope this helps. No, I don't have the address here (I'm at home).
--
Paul Gillingwater, paul@actrix.co.nz
------------------------------
Message-ID: <9006151740.AA01607@frieda.mitre.org>
Date: Fri, 15 Jun 90 13:40:52 EDT
From: ramsdell@linus.mitre.org
To: scheme@lcs.mit.edu, t-discussion@yale.edu
CC: ramsdell@linus.mitre.org
Subject: T3.1 for the nExt Silly Named Computer.
T has been ported to the NeXT Computers. The distribution is as a
compressed tar file in wheaties.ai.mit.edu:pub/nextt.tar.Z.
This version has the same bugs and features as Sun3 T3.1 (5) except
that dynamic loading of foreign functions does not work.
T is an object-oriented dialect of Scheme from Yale University. It
features an optimizing compiler and a Scheme compatibility mode.
John
P. S. If you have a version of nextt which does contain a README file, you
should get a new version.
------------------------------
End of Scheme Digest
********************
∂19-Jun-90 0113 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #399
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 19 Jun 90 01:13:42 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA09968; Tue, 19 Jun 90 04:04:21 EDT
Received: from lcs.mit.edu (mintaka.lcs.mit.edu) by zurich.ai.mit.edu; Tue, 19 Jun 90 04:01:40 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa02290;
19 Jun 90 3:31 EDT
Message-Id: <DIGEST.184.900619.024233.12@MC.LCS.MIT.EDU>
Date: 19 Jun 90 02:42:33 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #399
Scheme Digest #399 19 Jun 90 02:42:33 EDT
Today's Topics:
Current Version of PC Scheme
----------------------------------------------------------------------
Message-ID: <9006190152.AA12569@super.super.org>
Date: Mon, 18 Jun 90 21:52:54 EDT
From: Peter C Olsen <pcolsen@super.org>
To: Scheme@lcs.mit.edu
Subject: Current Version of PC Scheme
Would someone please tell me the current version of PC-Scheme?
I have 3.02. Has TI issued a subsequent major revision?
Thanks.
Peter Olsen, pcolsen@super.super.org
------------------------------
End of Scheme Digest
********************
∂19-Jun-90 2354 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #400
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 19 Jun 90 23:54:32 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA28452; Wed, 20 Jun 90 02:51:13 EDT
Received: from lcs.mit.edu (mintaka.lcs.mit.edu) by zurich.ai.mit.edu; Wed, 20 Jun 90 02:48:21 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa20614;
20 Jun 90 2:44 EDT
Message-Id: <DIGEST.184.900620.022737.18@MC.LCS.MIT.EDU>
Date: 20 Jun 90 02:27:37 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #400
Scheme Digest #400 20 Jun 90 02:27:37 EDT
Today's Topics:
In the search of Bob Courts
Current Version of PC Scheme (2 messages)
----------------------------------------------------------------------
Message-ID: <889@seti.inria.fr>
Date: 19 Jun 90 08:16:39 GMT
From: "delacour vincent @" <eru!luth!sunic!mcsun!inria!seti!delacour@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: In the search of Bob Courts
I'am actually looking for a report he wrote when being at TI's,
in 1987 :
"Improving Locality of Reference in a Garbage-Collecting
Memory Management System", Internal TI memo, November 1987.
This is how the reference appears in a POPL'90 paper (by
MM Demers, Weiser, & al).
Does anybody know how to get this report,
and/or how to reach M.Courts ?
Thanx in advance,
Vincent Delacour
-----
delacour@poly.polytechnique.fr
------------------------------
Message-ID: <24981@mimsy.umd.edu>
Date: 19 Jun 90 16:29:31 GMT
From: Rusty Haddock <steelmill.cs.umd.edu!rusty@mimsy.umd.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: Current Version of PC Scheme
In article <9006190152.AA12569@super.super.org> pcolsen@SUPER.ORG (Peter C Olsen) writes:
>Would someone please tell me the current version of PC-Scheme?
>I have 3.02. Has TI issued a subsequent major revision?
I have 3.03 but it's about at least two years old. I believe the
differences 'tween .02 and .03 are bug fixes.
I know some folks at TI read this news group so.... What is the
latest version folks??
-Rusty-
--
Rusty Haddock DOMAIN: rusty@mimsy.cs.umd.edu
Computer Science Department PATH: {uunet,rutgers}!mimsy!rusty
University of Maryland "IBM sucks silicon!"
College Park, Maryland 20742 -- PC Banana Jr,"Bloom County"
------------------------------
Message-ID: <10617@netcom.UUCP>
Date: 19 Jun 90 16:58:04 GMT
From: Isaac Rabinovitch <snorkelwacker!apple!netcom!ergo@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: Current Version of PC Scheme
In <9006190152.AA12569@super.super.org> pcolsen@SUPER.ORG (Peter C Olsen) writes:
>Would someone please tell me the current version of PC-Scheme?
>I have 3.02. Has TI issued a subsequent major revision?
*I* have 2.0, so obviously I'm even more out of date. Would someone
mind telling me if the later versions support Hercules graphics -- or
are at least sufficiently non-CGA that they don't lock up the system
when they redraw the screen?
------------------------------
End of Scheme Digest
********************
∂21-Jun-90 0000 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #401
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Jun 90 00:00:03 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA04393; Thu, 21 Jun 90 02:57:56 EDT
Received: from lcs.mit.edu (mintaka.lcs.mit.edu) by zurich.ai.mit.edu; Thu, 21 Jun 90 02:55:18 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa12077;
21 Jun 90 2:47 EDT
Message-Id: <DIGEST.184.900621.022612.2@MC.LCS.MIT.EDU>
Date: 21 Jun 90 02:26:11 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #401
Scheme Digest #401 21 Jun 90 02:26:11 EDT
Today's Topics:
In the search of Bob Courts
Free Prolog for Common Lisp/Scheme?
Current Version of PC Scheme
----------------------------------------------------------------------
Message-ID: <9006201609.AA24988@garlic.Stanford.EDU>
Date: Wed, 20 Jun 90 09:09:34 PDT
From: Morris Katz <mkatz@garlic.stanford.edu>
To: scheme@zurich.ai.mit.edu
Subject: Re: In the search of Bob Courts
I'am actually looking for a report he wrote when being at TI's,
in 1987 :
"Improving Locality of Reference in a Garbage-Collecting
Memory Management System", Internal TI memo, November 1987.
This is how the reference appears in a POPL'90 paper (by
MM Demers, Weiser, & al).
You are in luck. This paper was republished in Communications of the ACM,
Vol.31, No. 9, Sept. 1988, pp. 1128-1138. This version should be a lot easier
to get a hold of.
------------------------------------------------------------------------------
Morry Katz
katz@cs.stanford.edu
------------------------------------------------------------------------------
------------------------------
Message-ID: <8769@goofy.Apple.COM>
Date: 20 Jun 90 20:43:13 GMT
From: Walter Smith <bu.edu!rpi!zaphod.mps.ohio-state.edu!mips!apple!goofy!wrs@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Free Prolog for Common Lisp/Scheme?
I would like to use Prolog in a nicely-integrated fashion with an
existing system. The ideal thing would be a Prolog interpreter/compiler
written in and for Common Lisp or Scheme. Does such a thing exist,
preferably in a free (or "free") form?
I realize there are integrated things like POPLOG, but I need this to
run in a Lisp implementation that I already have.
Please email responses; I will summarize.
Thanks,
Walt
------------------------------
Message-ID: <368@fe2o3.UUCP>
Date: 20 Jun 90 12:56:12 GMT
From: Rusty Haddock <fe2o3!rusty@mimsy.umd.edu>
To: scheme@MC.lcs.mit.edu
Subject: Re: Current Version of PC Scheme
In article <10617@netcom.UUCP> ergo@netcom.UUCP (Isaac Rabinovitch) writes:
>In <9006190152.AA12569@super.super.org> pcolsen@SUPER.ORG (Peter C Olsen) writes:
>
>>Would someone please tell me the current version of PC-Scheme?
>>I have 3.02. Has TI issued a subsequent major revision?
>
>*I* have 2.0, so obviously I'm even more out of date. Would someone
>mind telling me if the later versions support Hercules graphics -- or
>are at least sufficiently non-CGA that they don't lock up the system
>when they redraw the screen?
As of 3.03 I have found no Hercules support but the graphics have
officially been extended to use some EGA and some VGA modes.
Per the ``User's Manual'':
"Currently, PC Scheme graphics are supported only for the IBM CGA
in graphics mode 4 and the [EGA] in modes 4,14, and 16. Many of
the newer boards from IBM emulate the various display modes of the
CGA while adding newer modes of their own. Graphics operations
performed in other modes will work, but functionality may be reduced
or the operation of a function may differ from the way it works in
mode 4."
Per the READ.ME file on the distribution disk:
"3. %GRAPHICS for EGA has been reimplemented to do direct screen
writes. This gives a significant performance boost at the
expense of generality, which may affect some EGA clones. Also,
VGA modes 17 and 18 are now supported."
Basically, most anything you can do via INT 10h, with regards to
graphics, (e.g. change video mode, set palette, draw point, etc)
is do-able in PC Scheme. That's basically why there's no Hercules
support -- the Herc' board doesn't support the INT 10h BIOS entry
point. To use the other graphics modes (and I have) study of the
%GRAPHICS function will be required. At least that's the way I
wrote the original graphics portion of PCS. How the current crew
at TI has changed my code I haven't the foggiest.
-Rusty-
--
Rusty Haddock o {uunet,rutgers}!mimsy.umd.edu!fe2o3!rusty
Laurel, Maryland o rusty%fe2o3@mimsy.umd.edu
-=> This .signature protected by Smith & Wesson <=-
------------------------------
End of Scheme Digest
********************
∂21-Jun-90 2342 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #402
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Jun 90 23:42:35 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA21435; Fri, 22 Jun 90 02:36:06 EDT
Received: from lcs.mit.edu (mintaka.lcs.mit.edu) by zurich.ai.mit.edu; Fri, 22 Jun 90 02:33:28 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa02603;
22 Jun 90 2:27 EDT
Message-Id: <DIGEST.184.900622.021112.5@MC.LCS.MIT.EDU>
Date: 22 Jun 90 02:11:12 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #402
Scheme Digest #402 22 Jun 90 02:11:12 EDT
Today's Topics:
Threaded interpreters for Lisp or Scheme?
Is T available for the Mac?
Current Version of PC Scheme
PC Board router in scheme
----------------------------------------------------------------------
Message-ID: <1990Jun21.094828.29673@iesd.auc.dk>
Date: 21 Jun 90 09:48:28 GMT
From: Kasper Osterbye <eru!luth!sunic!dkuug!iesd!kasper@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: Threaded interpreters for Lisp or Scheme?
In article <136989@sun.Eng.Sun.COM> vladimir@prosper (Vladimir G. Ivanovic) writes:
>In v25 #2 of SIGPLAN Notices (February 1990), David J. Nordstrom of DePaul
>University contributed an article called "Threading Lisp." From the
>introduction:
>
> This article describes a simple method of implementing a threaded
> interpreter (TI) for Lisp. TIs are fast, space-efficient, flexible, readily
> extensible, and easy to implement since much (or most) of the interpreter can
> be written in the language implemented by the interpreter.
>
>Can anyone point me to an implementation of a TI for Lisp or Scheme? The ideal
>would be a version in C for SPARCstations running SunOS 4.0.3c (but that's
>asking for a lot!) Any help would be greatly appreciated.
>
>Vladimir G. Ivanovic vladimir@sun.com
>M/S MTV12-33 vivanovic@sun.com
>Sun Microsystems, Inc.
>2550 Garcia Ave.
>Mountain View, CA 94043-1100 (415) 336-2315
While TI are nice, and the referenced paper explains that it can be
done, it is not apparent that the author discusses how to have the
TI do garbage collection, which is a integrated part of Lisp. I am
therefore not sure that the TI implementation is as easy as it is
presented in that SIGPLAN issue.
-- Kasper
--
Kasper Osterbye Internet: kasper@iesd.auc.dk
Institute for electronic systems UUCP: ...!mcvax!iesd!kasper
Strandvejen 19, 9000 Aalborg
DENMARK. (W) +45 98 13 87 88-285 (H) +45 98 37 30 65
------------------------------
Message-ID: <90170.134041KPURCELL@LIVERPOOL.AC.UK>
Date: 19 Jun 90 12:40:41 GMT
From: eru!luth!sunic!mcsun!ukc!mucs!liv-cs!liv!kpurcell@bloom-beacon.mit.edu
To: scheme@mc.lcs.mit.edu
Subject: Is T available for the Mac?
I remember reading in a paper on T that it was originally built on the Mac.
Is it generally available? How can I get it?
Any help or pointers would be welcome.
Please email to:
Kevin Purcell ________________________________________ kpurcell@uk.ac.liverpool
SURFACE SCIENCE CENTRE | Stepwise Refinement n. A sequence of kludges K,
Liverpool University | neither distinct or finite, applied to a program P
Liverpool L69 3BX | aimed at transforming it into the target program Q.
------------------------------
Message-ID: <1990Jun20.200242.21909@ibmpcug.co.uk>
Date: 20 Jun 90 20:02:42 GMT
From: Douglas Clinton <eru!luth!sunic!mcsun!ukc!slxsys!ibmpcug!clint@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: Current Version of PC Scheme
In article <10617@netcom.UUCP> ergo@netcom.UUCP (Isaac Rabinovitch) writes:
> In <9006190152.AA12569@super.super.org> pcolsen@SUPER.ORG (Peter C Olsen) writes:
> *I* have 2.0, so obviously I'm even more out of date. Would someone
> mind telling me if the later versions support Hercules graphics -- or
> are at least sufficiently non-CGA that they don't lock up the system
> when they redraw the screen?
I have version 3.03 which I believe is the latest (though it is two years
old). No, it does not support Hercules graphics unfortunately. I'm not
sure what you mean about locking up the system redrawing the screen.
Doug
--
Automatic Disclaimer:
The views expressed above are those of the author alone and may not
represent the views of the IBM PC User Group.
--
------------------------------
Message-ID: <9006211659.aa02038@mc.lcs.mit.edu>
Date: 21 Jun 90 14:21:00 MDT
From: "1412 Davidson, George S." <gsdavid@sandia.gov>
To: scheme <scheme@mc.lcs.mit.edu>
Subject: PC Board router in scheme
If anyone has a router written in scheme that is freely available
I would be interested in trying it. I only need a double layer router
for my curre application.
Thanks--
george davidson
gsdavid@sandia.gov
------------------------------
End of Scheme Digest
********************
∂23-Jun-90 0054 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #403
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Jun 90 00:54:13 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA15041; Sat, 23 Jun 90 03:51:39 EDT
Received: from lcs.mit.edu (mintaka.lcs.mit.edu) by zurich.ai.mit.edu; Sat, 23 Jun 90 03:49:03 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa21771;
23 Jun 90 3:39 EDT
Message-Id: <DIGEST.184.900623.025614.10@MC.LCS.MIT.EDU>
Date: 23 Jun 90 02:56:14 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #403
Scheme Digest #403 23 Jun 90 02:56:14 EDT
Today's Topics:
OSS package for Scheme?
threaded interpreters
Current Version of PC Scheme
Threaded interpreters for Lisp or Scheme?
----------------------------------------------------------------------
Message-ID: <3308@goanna.cs.rmit.oz.au>
Date: 22 Jun 90 10:03:10 GMT
From: "Richard A. O'Keefe" <snorkelwacker!bu.edu!rpi!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!goanna!ok@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: OSS package for Scheme?
Has anyone converted the OSS (letS) package to Scheme?
--
"private morality" is an oxymoron, like "peaceful war".
------------------------------
Message-ID: <9006221543.AA07851@mailhost.samsung.com>
Date: Fri, 22 Jun 90 09:21:02 EDT
From: gjc@mitech.com
Reply-To: gjc@mitech.com
To: scheme@lcs.mit.edu
Subject: threaded interpreters
What is the definition of a threaded interpreter?
Which requirements:
(1) instead of dispatching off a TYPE code always call a procedure at
each node.
(2) instead of going through a binding/reference for commonly used functions,
go directly to the machine code in question.
(3) code represented as a vector of tokens/procedures instead of as a tree
(vector or list trees?)
If you want to have #2 and can live with a tree representation of code
then a simple pre-evaluation of the car of mosts lists will give you what
you want. e.g. in SIOD version 2.4 on a vaxstation-3100:
In this example all the previously defined primitives are pre-evaluated
in the case of SFIB, but the call to SFIB itself must go through a symbol,
since it is not defined yet. It would take a RPLACA operation on the
code itself (not provided currently in SIOD) to get rid of that.
Is this threaded enough?
(define (standard-fib x)
(if (< x 2)
x
(+ (standard-fib (- x 1))
(standard-fib (- x 2)))))
(define sfib
(eval `(lambda (x)
(,if (,< x 2)
x
(,+ (sfib (,- x 1))
(sfib (,- x 2)))))))
$ siod -h50000 -isiod.scm -g0
Welcome to SIOD, Scheme In One Defun, Version 2.4
(C) Copyright 1988, 1989, 1990 Paradigm Associates Inc.
heap_size = 50000 cells, 600000 bytes. GC is mark and sweep
loading siod.scm
done.
> standard-fib
Evaluation took 0 seconds (0 in gc) 0 cons work
#<CLOSURE (x) (if (< x 2) x
(+ (standard-fib (- x 1)) (standard-fib (- x 2))))>
> sfib
Evaluation took 0 seconds (0 in gc) 0 cons work
#<CLOSURE (x) (#<SUBR(10) if>
(#<SUBR(6) <> x 2) x
(#<SUBR(6) +> (sfib (#<SUBR(6) -> x 1))
(sfib (#<SUBR(6) -> x 2))))>
> (standard-fib 15)
Evaluation took 1.23 seconds (0 in gc) 8877 cons work
610
> (sfib 15)
Evaluation took 1.04 seconds (0 in gc) 8877 cons work
610
------------------------------
Message-ID: <1990Jun22.160009.16699@calgary.uucp>
Date: 22 Jun 90 16:00:09 GMT
From: Andrew Ginter <ubc-cs!calgary!cpsc!gintera@beaver.cs.washington.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: Current Version of PC Scheme
A number of people have recently posted claims that PC Scheme graphics
don't work on Hercules adapters. I have both PC Scheme and a Hercules
and the two don't work together unassisted, no. But there's a
shareware utility (whose name escapes me right now) that makes a
Hercules adapter pretend it's a CGA adapter. With this in place, PC
Scheme graphics have worked fine for me for the little use I've had
for them.
If you want the shareware utility, just call up your local PC BBS -
the thing has been around for a long time.
Andrew Ginter, 403-282-2984, gintera@CPSC.UCALGARY.CA, Ginter@UNCAMULT.BITNET
------------------------------
Message-ID: <1990Jun22.154925.15967@calgary.uucp>
Date: 22 Jun 90 15:49:25 GMT
From: Andrew Ginter <ubc-cs!calgary!cpsc!gintera@beaver.cs.washington.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: Threaded interpreters for Lisp or Scheme?
> While TI are nice, and the referenced paper explains that it can be
> done, it is not apparent that the author discusses how to have the
> TI do garbage collection, which is a integrated part of Lisp. I am
> therefore not sure that the TI implementation is as easy as it is
> presented in that SIGPLAN issue.
Compiling lisp to a threaded interpreter is a little tricky if the
interpreter is to be integrated to any degree with the original lisp.
If the threaded interpreter is treated as just a "machine language" to
which the compiler is targeted though, compiling to the interpreter is
every bit as simple as compiling to any other machine (I've tried it).
Garbage collection is every bit as simple in the threaded interpreter
as it is in any other machine language.
Andrew Ginter, 403-282-2984, gintera@CPSC.UCALGARY.CA, Ginter@UNCAMULT.BITNET
------------------------------
End of Scheme Digest
********************
∂25-Jun-90 0005 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #404
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 25 Jun 90 00:05:40 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA01755; Mon, 25 Jun 90 03:02:37 EDT
Received: from lcs.mit.edu (mintaka.lcs.mit.edu) by zurich.ai.mit.edu; Mon, 25 Jun 90 02:59:51 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa04977;
25 Jun 90 2:56 EDT
Message-Id: <DIGEST.184.900625.022614.15@MC.LCS.MIT.EDU>
Date: 25 Jun 90 02:26:14 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #404
Scheme Digest #404 25 Jun 90 02:26:14 EDT
Today's Topics:
Bug and fix in XScheme
----------------------------------------------------------------------
Message-ID: <38100004@m.cs.uiuc.edu>
Date: 24 Jun 90 02:04:00 GMT
From: bu.edu!rpi!uwm.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!m.cs.uiuc.edu!jfernand@bloom-beacon.mit.edu
To: scheme@mc.lcs.mit.edu
Subject: Bug and fix in XScheme
Bug in XScheme (up to release 0.22):
> (QUOTIENT 4 2 0)
error: division by zero <---- detected and handled by interpreter
..
> (QUOTIENT 4 0)
divide by zero exception <---- probably detected by processor, anyway,
this results in program termination
Fix: in xsint.c
/* xlexecute - execute byte codes */
xlexecute(fun)
LVAL fun;
{
...
int tmpfix; /* include this line with the local variable declarations */
...
switch(*pc++) {
...
case OP_QUO:
tmp = pop();
if (fixp(xlval) && fixp(tmp)) {
if ((tmpfix = getfixnum(tmp)) == 0) /* add this check */
xlfail("div. by zero");
xlval = cvfixnum(getfixnum(xlval) / tmpfix);
}
else if (fixp(xlval))
badargtype(tmp);
else
badargtype(xlval);
break;
...
}
--
Jose R. Fernandez
------------------------------
End of Scheme Digest
********************
∂26-Jun-90 0022 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #405
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 26 Jun 90 00:21:57 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA20635; Tue, 26 Jun 90 03:05:50 EDT
Received: from lcs.mit.edu (mintaka.lcs.mit.edu) by zurich.ai.mit.edu; Tue, 26 Jun 90 02:59:49 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa27693;
26 Jun 90 2:46 EDT
Message-Id: <DIGEST.184.900626.021115.18@MC.LCS.MIT.EDU>
Date: 26 Jun 90 02:11:14 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #405
Scheme Digest #405 26 Jun 90 02:11:14 EDT
Today's Topics:
Eval Usage
----------------------------------------------------------------------
Message-ID: <863.26877c03@waikato.ac.nz>
Date: 26 Jun 90 03:15:15 GMT
From: munnari.oz.au!uhccux!virtue!math1205@uunet.uu.net
To: scheme@mc.lcs.mit.edu
Subject: Eval Usage
Could somebody please explain why the revised**3 report of Scheme does not
specify the function eval ? Is the reason related to the problems of which
environment to perform the evaluation in, i.e. the current one or the global
environment (the lexical environment for eval)?
We have DEC's Scheme->C which has introduced the function eval using the global
environment. But I have seen mention of the MIT Scheme using eval with the
environment explicitly given as an argument. This approach seems much more
useful especially if the environment argument is optional and defaults to
the global environment. Having an explicit environment means functions must be
available in MIT Scheme to construct and extract existing environments; is this
the case and are there any such functions specified in R**3RS?
What is the general opinion on eval usage and of the construction and
manipulation of environments?
Wayne Schou
math1205@waikato.ac.nz
------------------------------
End of Scheme Digest
********************
∂27-Jun-90 0048 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #406
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 27 Jun 90 00:48:28 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA08523; Wed, 27 Jun 90 03:35:33 EDT
Received: from lcs.mit.edu (mintaka.lcs.mit.edu) by zurich.ai.mit.edu; Wed, 27 Jun 90 03:27:43 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa21402;
27 Jun 90 3:17 EDT
Message-Id: <DIGEST.184.900627.024542.2@MC.LCS.MIT.EDU>
Date: 27 Jun 90 02:45:41 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #406
Scheme Digest #406 27 Jun 90 02:45:41 EDT
Today's Topics:
MIT-Scheme 7.0 for 386/ix
Need help with MIT C Scheme
Eval Usage
1 message without subject
----------------------------------------------------------------------
Message-ID: <15706.9006261117@isis.educ.lon.ac.uk>
Date: Tue, 26 Jun 90 12:17:18-0000
From: Richard Noss <rnoss%ISIS.EDUC.LON.AC.UK@mitvma.mit.edu>
To: scheme@mc.lcs.mit.edu
On the 1st July 1990 my site address will be changing to
UK.AC.LON.IOE
Please use the new sitename in the address when sending e-mail
after the 1st of July.
------------------------------
Message-ID: <3092@tuminfo1.lan.informatik.tu-muenchen.dbp.de>
Date: 26 Jun 90 13:11:34 GMT
From: Thomas Roell <eru!luth!sunic!mcsun!unido!fauern!tumuc!lan!roell@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: MIT-Scheme 7.0 for 386/ix
Because so may people had asked me for the diffs to get MIT-scheme 7.0 running
on 386/ix I post then here for everybody. All you have to do is to apply the
patches (using 'patch -p0 <diffs') on top of the microcode directory. You
should note that you have to adjust several include files for your local site,
to specify where scheme can find it's neccessary files.
All these patches were used by me only with GNU CC.
Have fun with it.
---------------------------------- cut -------------------------------------
diff -rc microcode.old/config.h microcode/config.h
*** microcode.old/config.h Mon Jun 12 18:08:28 1989
--- microcode/config.h Tue Jan 23 20:47:11 1990
***************
*** 212,217 ****
--- 212,219 ----
#define FASL_ALLIANT 13
#define FASL_SUN4 14
#define FASL_MIPS 15
+ #define FASL_IX386 16
+
!
/* These (pdp10 and nu) haven't worked in a while.
* Should be upgraded or flushed some day.
***************
*** 538,547 ****
#define BELL '\007'
#endif
!
! /* Make sure that some definition applies.
! If this error occurs, and the parameters of the
! configuration are unknown, try the Wsize program.
! */
#ifndef CHAR_SIZE
#include "Error: config.h: Unknown configuration."
--- 540,566 ----
#define BELL '\007'
#endif
!
!
! #ifdef ix386
! #define MACHINE_TYPE "i386"
! #define FASL_INTERNAL_FORMAT FASL_IX386
!
! #define BELL '\007'
! #define Heap_In_Low_Memory
! #define UNSIGNED_SHIFT
! #define HAS_FLOOR
! #define HAS_FREXP
! #define VAX_BYTE_ORDER 1
! #define CHAR_SIZE 8
! #define USHORT_SIZE 16
! #define ULONG_SIZE 32
! #define DBFLT_SIZE 64
! /* should be IEEE */
! #define FLONUM_MANTISSA_BITS 53
! #define FLONUM_EXPT_SIZE 10
! #define MAX_FLONUM_EXPONENT 1023
!
! #endif
#ifndef CHAR_SIZE
#include "Error: config.h: Unknown configuration."
Only in microcode: config.h.orig
diff -rc microcode.old/config.sh microcode/config.sh
*** microcode.old/config.sh Wed Jul 26 06:17:38 1989
--- microcode/config.sh Tue Jan 23 20:56:53 1990
***************
*** 88,93 ****
--- 88,98 ----
cmp_file=sun-nfp/cmp68020.s
cmp_link=cmp68020.s
;;
+ ix386)
+ system_file=ix386
+ machine_file=ix386
+ mfour_file=sysV
+ ;;
*)
echo "$progname: unknown machine name: $machine"
exit 1
Only in microcode: config.status
diff -rc microcode.old/cterm.c microcode/cterm.c
*** microcode.old/cterm.c Fri Jun 16 11:38:40 1989
--- microcode/cterm.c Tue Jan 23 21:27:22 1990
***************
*** 43,48 ****
--- 43,52 ----
#define HAS_HAIRY_CURSES
#endif
+ #ifdef ix386
+ #define HAS_HAIRY_CURSES
+ #endif
+
#define CURSES_CHECK(value) \
{ \
if ((value) == ERR) \
diff -rc microcode.old/unix.c microcode/unix.c
*** microcode.old/unix.c Tue Jul 25 10:51:35 1989
--- microcode/unix.c Tue Jan 23 21:33:44 1990
***************
*** 1589,1595 ****
!
/* Keyboard I/O and interrupts */
! #if defined(CBREAK) /* BSD */
#define INITIALIZE_READER_STATE() \
do {} while (0)
--- 1589,1595 ----
!
/* Keyboard I/O and interrupts */
! #if defined(CBREAK) && !defined(ix386) /* BSD */
#define INITIALIZE_READER_STATE() \
do {} while (0)
***************
*** 1629,1635 ****
}
#else
! #if defined(TCSETA) /* ATT, hpux */
!
static Boolean initial_echo_p = true;
--- 1629,1635 ----
}
#else
! #if defined(TCSETA) || defined(ix386) /* ATT, hpux */
!
static Boolean initial_echo_p = true;
***************
*** 1672,1678 ****
(& (current_reader_state -> new_termio))); \
}
! #define READER_STATE_BUFFERED(only_polling) \
{ \
ioctl ((fileno (stdin)), TCGETA, \
(& (current_reader_state -> saved_termio))); \
--- 1672,1678 ----
(& (current_reader_state -> new_termio))); \
}
! #define READER_STATE_BUFFERED() \
{ \
ioctl ((fileno (stdin)), TCGETA, \
(& (current_reader_state -> saved_termio))); \
***************
*** 2611,2617 ****
/*NOTREACHED*/
}
! #if defined(hpux)
#define NICE_DELTA 5
static SIGTYPE
--- 2611,2617 ----
/*NOTREACHED*/
}
! #if defined(hpux) || defined(ix386)
#define NICE_DELTA 5
static SIGTYPE
diff -rc microcode.old/unixprim.c microcode/unixprim.c
*** microcode.old/unixprim.c Tue Mar 14 02:59:01 1989
--- microcode/unixprim.c Tue Jan 23 21:46:20 1990
***************
*** 521,527 ****
--- 521,529 ----
int fd;
char buf [1];
+ #ifndef ix386
extern int ftruncate ();
+ #endif
extern int lseek ();
extern int open ();
extern int read ();
***************
*** 535,541 ****
struct timeval tvp [2];
extern int utimes ();
#else /* not bsd */
! #ifdef hpux
extern int utime ();
#endif /* hpux */
#endif /* bsd */
--- 537,543 ----
struct timeval tvp [2];
extern int utimes ();
#else /* not bsd */
! #if defined(hpux) || defined(ix386)
extern int utime ();
#endif /* hpux */
#endif /* bsd */
***************
*** 571,577 ****
return (SHARP_F);
#else /* not bsd */
! #ifdef hpux
result = (utime (filename, 0));
if (result == 0)
--- 573,579 ----
return (SHARP_F);
#else /* not bsd */
! #if defined(hpux) || defined(ix386)
result = (utime (filename, 0));
if (result == 0)
***************
*** 608,614 ****
--- 610,620 ----
}
if ((lseek (fd, 0, 0)) != 0)
{
+
+ #ifndef ix386
(void) ftruncate (fd, 0);
+ #endif
+
(void) close (fd);
return (system_error_message ("lseek"));
}
***************
*** 618,636 ****
--- 624,648 ----
if (result > 0) break;
if (result == 0)
{
+ #ifndef ix386
(void) ftruncate (fd, 0);
+ #endif
(void) close (fd);
return (C_String_To_Scheme_String ("read: eof encountered"));
}
if ((result < 0) && (errno != EINTR))
{
+ #ifndef ix386
(void) ftruncate (fd, 0);
+ #endif
(void) close (fd);
return (system_error_message ("read"));
}
}
+ #ifndef ix386
if ((ftruncate (fd, 0)) != 0)
return (system_error_message ("ftruncate"));
+ #endif
if ((close (fd)) != 0)
return (system_error_message ("close"));
return (SHARP_F);
diff -rc microcode.old/m/ix386.h microcode/m/ix386.h
*** microcode.old/m/ix386.h Tue Jun 26 14:43:54 1990
--- microcode/m/ix386.h Tue Jan 23 20:53:30 1990
***************
*** 0 ****
--- 1,36 ----
+ /* -*-C-*-
+ Machine file for Interactive 386/ix
+
+
+ Copyright (c) 1989 Massachusetts Institute of Technology
+
+ This material was developed by the Scheme project at the Massachusetts
+ Institute of Technology, Department of Electrical Engineering and
+ Computer Science. Permission to copy this software, to redistribute
+ it, and to use it for any purpose is granted, subject to the following
+ restrictions and understandings.
+
+ 1. Any copy made of this software must include this copyright notice
+ in full.
+
+ 2. Users of this software agree to make their best efforts (a) to
+ return to the MIT Scheme project any improvements or extensions that
+ they make, so that these may be included in future releases; and (b)
+ to inform MIT of noteworthy uses of this software.
+
+ 3. All materials developed as a consequence of the use of this
+ software shall duly acknowledge such use, in accordance with the usual
+ standards of acknowledging credit in academic research.
+
+ 4. MIT has made no warrantee or representation that the operation of
+ this software will be error-free, and MIT is under no obligation to
+ provide any services, by way of maintenance, update, or otherwise.
+
+ 5. In conjunction with products arising from the use of this material,
+ there shall be no use of the name of the Massachusetts Institute of
+ Technology nor of any adaptation thereof in any advertising,
+ promotional, or sales literature without prior written consent from
+ MIT in each case. */
+
+ #define PROC_TYPE PROC_TYPE_UNKNOWN
+
diff -rc microcode.old/s/ix386.h microcode/s/ix386.h
*** microcode.old/s/ix386.h Tue Jun 26 14:44:17 1990
--- microcode/s/ix386.h Tue Jan 23 21:04:44 1990
***************
*** 0 ****
--- 1,46 ----
+ /* -*-C-*-
+ System file for Ineractive 386/ix
+
+ $Header: hpux.h,v 1.3 89/07/26 23:59:35 GMT cph Rel $
+
+ Copyright (c) 1989 Massachusetts Institute of Technology
+
+ This material was developed by the Scheme project at the Massachusetts
+ Institute of Technology, Department of Electrical Engineering and
+ Computer Science. Permission to copy this software, to redistribute
+ it, and to use it for any purpose is granted, subject to the following
+ restrictions and understandings.
+
+ 1. Any copy made of this software must include this copyright notice
+ in full.
+
+ 2. Users of this software agree to make their best efforts (a) to
+ return to the MIT Scheme project any improvements or extensions that
+ they make, so that these may be included in future releases; and (b)
+ to inform MIT of noteworthy uses of this software.
+
+ 3. All materials developed as a consequence of the use of this
+ software shall duly acknowledge such use, in accordance with the usual
+ standards of acknowledging credit in academic research.
+
+ 4. MIT has made no warrantee or representation that the operation of
+ this software will be error-free, and MIT is under no obligation to
+ provide any services, by way of maintenance, update, or otherwise.
+
+ 5. In conjunction with products arising from the use of this material,
+ there shall be no use of the name of the Massachusetts Institute of
+ Technology nor of any adaptation thereof in any advertising,
+ promotional, or sales literature without prior written consent from
+ MIT in each case. */
+
+ /* This says we have curses terminal support for Edwin. */
+ #define HAVE_CURSES
+
+ /* No special libraries are needed for debugging. */
+ #define LIB_DEBUG
+
+ #define C_SWITCH_SYSTEM -Dix386 -Dsysv -Dunix
+
+ #define SOURCES_SYSTEM unixprim.c
+ #define OBJECTS_SYSTEM unixprim.o
+
------------------------------------- cut -----------------------------------
- Thomas
--
_______________________________________________________________________________
Mail: Thomas Roell (c/o Daniel Hernandez)
Inst. f. Informatik / Technische Universitaet M"unchen
Arcisstr. 21 / 8000 Munich 2 / Fed.Rep. of Germany
E-Mail (domain): roell@lan.informatik.tu-muenchen.dbp.de
UUCP (when above fails): roell@tumult.{uucp | informatik.tu-muenchen.de}
------------------------------------------------------------------------------
------------------------------
Message-ID: <DRW.90Jun26104437@hermite.mit.edu>
Date: 26 Jun 90 10:44:37
From: "Dale R. Worley" <math.mit.edu!drw@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: Need help with MIT C Scheme
OK, I'm probably doing something dumb, but I can't tell what it is.
The problem is that I have MIT C Scheme 7.0 up and running, but thee
running is more like crawling. On an unloaded Sun 3, even the
simplest operations (like (+ 2 3)) take several seconds. I presume
that I've done something stupid (like not compiling the interpreter?)
that really hurts performance but doesn't actually break anything.
Would anyone out there know what it might be?
Thanks,
Dale
drw@math.mit.edu
------------------------------
Message-ID: <9006261902.AA18646@zurich.ai.mit.edu>
Date: Tue, 26 Jun 90 15:02:06 edt
From: "Guillermo J. Rozas" <jinx@zurich.ai.mit.edu>
Reply-To: jinx@zurich.ai.mit.edu
To: munnari.oz.au!uhccux!virtue!math1205@uunet.uu.net
CC: scheme@zurich.ai.mit.edu
Subject: Eval Usage
We have DEC's Scheme->C which has introduced the function eval
using the global environment. But I have seen mention of the MIT
Scheme using eval with the environment explicitly given as an
argument. This approach seems much more useful especially if the
environment argument is optional and defaults to the global
environment. Having an explicit environment means functions must
be available in MIT Scheme to construct and extract existing
environments; is this the case and are there any such functions
specified in R**3RS?
What is the general opinion on eval usage and of the construction and
manipulation of environments?
MIT Scheme has a combination of procedures and special forms to
manipulate environments, and so does T (they are called "locales" in
T). First-class environments are not an agreed-upon feature, however,
so R↑nRS does not have them.
------------------------------
End of Scheme Digest
********************
∂29-Jun-90 0026 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #407
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 29 Jun 90 00:26:45 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA17245; Fri, 29 Jun 90 03:16:29 EDT
Received: from lcs.mit.edu (mintaka.lcs.mit.edu) by zurich.ai.mit.edu; Fri, 29 Jun 90 03:11:06 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa21373;
29 Jun 90 3:05 EDT
Message-Id: <DIGEST.184.900629.021542.6@MC.LCS.MIT.EDU>
Date: 29 Jun 90 02:15:42 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #407
Scheme Digest #407 29 Jun 90 02:15:42 EDT
Today's Topics:
Internal Definitions
Is the R4 report out yet?
----------------------------------------------------------------------
Message-ID: <904.268b61d9@waikato.ac.nz>
Date: 29 Jun 90 02:12:41 GMT
From: comp.vuw.ac.nz!virtue!math1205@uunet.uu.net
To: scheme@mc.lcs.mit.edu
Subject: Internal Definitions
In a book by H. Abelson & G. Sussman entitled "Structure and Interpretation
of Computer Programs" (1985) there is a section on the evaluation of internal
definitions (pp. 439-442). In here they show there are several ways to evaluate
multiple internal definitions which can lead to inconsistent results when the
definitions reference each other.
For example, the expression
(let ((a 1))
(define (f x)
(define b (+ a x))
(define a 5)
(+ a b))
(f 10))
can return different results depending on whether the definition of a and b
are evaluated simultaneously or in sequence; returning 20 or 16 resp. The book
suggests a simultaneous evaluation of definitions is the desired approach, but
because this is difficult to implement, they note the MIT implementors of
Scheme generate an error in the above case.
As I see the Scheme description given in R↑nRS, expressions in the body of f
should be evaluated in sequence and therefore the above should return 16.
Who agrees/disagrees?
Also in the DEC Scheme->C implementation the above expression returns the rather
confusing value of 15. I assume this is caused by a having the value of 0 when
the definition of b is evaluated. I think this is a bug!
Who agrees/disagrees?
-Wayne Schou
math1205@waikato.ac.nz
------------------------------
Message-ID: <10340001@hpfcso.HP.COM>
Date: 28 Jun 90 23:26:10 GMT
From: Dave Roberts <hpfcso!dgr@hplabs.hpl.hp.com>
To: scheme@mc.lcs.mit.edu
Subject: Re: Is the R4 report out yet?
R↑4RS is still in the making, right? Aren't we still at R↑3.99RS?
Are copies of 3.99 available or are those being kept under wraps until
4 becomes available. If copies of 3.99 are available, would someone
be willing to send me a copy in TeX source format, shar'd up so the
mailer doesn't barf on it. My subnet here at HP is closed, so FTP
sites, although possible, are really a pain to get to. Just send me a
note first if you've got the TeX and I'll choose someone and ask for
it. I don't want 20 copies of the whole document worming their way
through all the mail daemons from here to Australia. :-)
Thanks,
Dave Roberts
Hewlett-Packard Co.
dgr@hpfcla.hp.com
------------------------------
End of Scheme Digest
********************
∂30-Jun-90 0209 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #408
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 30 Jun 90 02:09:05 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA06492; Sat, 30 Jun 90 04:59:05 EDT
Received: from lcs.mit.edu (mintaka.lcs.mit.edu) by zurich.ai.mit.edu; Sat, 30 Jun 90 04:52:31 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa00488;
30 Jun 90 4:45 EDT
Message-Id: <DIGEST.184.900630.020043.11@MC.LCS.MIT.EDU>
Date: 30 Jun 90 02:00:43 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #408
Scheme Digest #408 30 Jun 90 02:00:43 EDT
Today's Topics:
Scheme R↑3 Report FTPable?
Internal Definitions (2 messages)
Internal definitions, DEC Scheme->C
----------------------------------------------------------------------
Message-ID: <259@huntsai.UUCP>
Date: 27 Jun 90 11:36:12 GMT
From: George Williams <ssc-vax!bcsaic!huntsai!george@beaver.cs.washington.edu>
To: scheme@mc.lcs.mit.edu
Subject: Scheme R↑3 Report FTPable?
Is the Scheme R↑3 report available for anonymous FTP?
If so, please mail or post the site & path.
Thanks in advance,
--
George Williams
E-Mail: george@huntsai.boeing.com Phone: 205+461-2597 BTN: 861-2597
USMail: Boeing Computer Services, POBox 240002, JA-74, Huntsville AL 35824-6402
<< Disclaimer: Boeing is not responsible for my opinions, nor I for theirs. >>
------------------------------
Message-ID: <9006291433.AA10350@zurich.ai.mit.edu>
Date: Fri, 29 Jun 90 10:33:12 EDT
From: markf@zurich.ai.mit.edu
Reply-To: markf@zurich.ai.mit.edu
To: comp.vuw.ac.nz!virtue!math1205@uunet.uu.net, scheme@mc.lcs.mit.edu
Subject: Re: Internal Definitions
>> (let ((a 1))
>> (define (f x)
>> (define b (+ a x))
>> (define a 5)
>> (+ a b))
>> (f 10))
>> As I see the Scheme description given in R↑nRS, expressions in the body of f
>> should be evaluated in sequence and therefore the above should return 16.
>>
>> Who agrees/disagrees?
I disagree. Internal definitions are not like other expressions in the
body of let expressions (or procedures, or begin blocks, etc.). The
section in the reports on internal defines explains that the above
expression is equivalent to the following letrec:
(let ((a 1))
(define (f x)
(letrec ((b (+ a x))
(a 5))
(+ a b)))
(f 10))
The section on letrec says that it must be possible to evaluate each
initialization expression (e.g. "(+ a x)" and "5" in the above)
without referring to the value of any of the variables bound by the
letrec.
The above expression is in error since there is a reference to the
variable "a" in the initialization expression for the variable "b".
Note that the r3.99 (and the r4rs to come) explicitly mentions the
restriction with respect to internal defines. In r3rs the restriction
is implicit.
>> Also in the DEC Scheme->C implementation the above expression returns
>> the rather confusing value of 15. I assume this is caused by a having
>> the value of 0 when the definition of b is evaluated. I think this is
>> a bug!
>>
>> Who agrees/disagrees?
Naturally, I disagree again. Since the expression is in error, and the
report does not say that this error must be signalled, Scheme->C is
free to do anything it wants with the expression.
-Mark
Mark Friedman
MIT Artificial Intelligence Lab
545 Technology Sq.
Cambridge, Ma. 02139
markf@zurich.ai.mit.edu
------------------------------
Message-ID: <9006291615.AA28227@jove.pa.dec.com>
Date: Fri, 29 Jun 90 09:15:43 PDT
From: bartlett@wrl.dec.com
To: Scheme@lcs.mit.edu
CC: bartlett@wrl.dec.com
Subject: Re: Internal definitions, DEC Scheme->C
In a previous message, Wayne Schou (math1205@waikato.ac.nz) suggested that
the expression:
(let ((a 1))
(define (f x)
(define b (+ a x))
(define a 5)
(+ a b))
(f 10))
should evaluate to either 20 or 16.
>> As I see the Scheme description given in R↑nRS, expressions in the body of f
>> should be evaluated in sequence and therefore the above should return 16.
>> Who agrees/disagrees?
Disagree, according to R3RS,the effect of the program is undefined.
Section 5.2.2 of R3RS defines internal defines in terms of letrec, so
the above expression is really:
(let ((a 1))
(letrec ((f (lambda (x)
(letrec ((b (+ a x))
(a 5))
(+ a b)))))
(f 10)))
The last paragraph of section 4.2.2 of R3RS explains that a letrec of
this form violates an important restriction. Quoting R3RS "it must be
possible to evaluate each <init> without referring to the value of any
<variable>. If this restriction is violated, then the effect is
undefined, and an error may be signalled during the evaluation of the <init>s."
>> Also in the DEC Scheme->C implementation the above expression returns the
>> rather confusing value of 15. I assume this is caused by a having the value
>> of 0 when the definition of b is evaluated. I think this is a bug!
>> Who agrees/disagrees?
Disagree as the value of the program is undefined. I will agree with
you though that error signals on undefined operations are often more
desirable than implementation specific values.
------------------------------
Message-ID: <1990Jun29.155446.6681@Neon.Stanford.EDU>
Date: 29 Jun 90 15:54:46 GMT
From: Max Hailperin <eos!shelby!neon!max@ames.arc.nasa.gov>
To: scheme@mc.lcs.mit.edu
Subject: Re: Internal Definitions
In article <904.268b61d9@waikato.ac.nz> math1205@waikato.ac.nz writes:
>In a book by H. Abelson & G. Sussman entitled "Structure and Interpretation
>of Computer Programs" (1985) there is a section on the evaluation of internal
>definitions (pp. 439-442). In here they show there are several ways to evaluate
>multiple internal definitions which can lead to inconsistent results when the
>definitions reference each other.
>
>For example, the expression
>(let ((a 1))
> (define (f x)
> (define b (+ a x))
> (define a 5)
> (+ a b))
> (f 10))
>can return different results depending on whether the definition of a and b
>are evaluated simultaneously or in sequence; returning 20 or 16 resp. The book
>suggests a simultaneous evaluation of definitions is the desired approach, but
>because this is difficult to implement, they note the MIT implementors of
>Scheme generate an error in the above case.
>As I see the Scheme description given in R↑nRS, expressions in the body of f
>should be evaluated in sequence and therefore the above should return 16.
>
>Who agrees/disagrees?
I disagree. Yes, the *expressions* in the body of f should be evaluated in
sequence, but technically definitions are not expressions, if you read R↑3R
carefully. Definitions are treated differently; they are treated as a letrec.
Letrec is defined such that it is an error, which the implementation *may*
signal, to do something such as the example. If you used the actual formal
semantics expansion, an error would indeed be signaled. But, it is explicitly
sanctioned to omit this. Under this guise of a "non-signaled error," it is
legal to extend the semantics to work the way you expect, and some
implementations do. However, it is also equally legal to not signal the
error, but do something else other than your sequential version. This explains
the Scheme->C result you observed. Therefore, I disagree with you on that
as well.
------------------------------
End of Scheme Digest
********************
∂01-Jul-90 1039 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #409
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Jul 90 10:39:20 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA15643; Sun, 1 Jul 90 12:56:16 EDT
Received: from lcs.mit.edu (mintaka.lcs.mit.edu) by zurich.ai.mit.edu; Sun, 1 Jul 90 03:13:42 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa13053;
1 Jul 90 3:11 EDT
Message-Id: <DIGEST.184.900701.030043.13@MC.LCS.MIT.EDU>
Date: 1 Jul 90 03:00:43 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #409
Scheme Digest #409 1 Jul 90 03:00:43 EDT
Today's Topics:
call/cc (2 messages)
xscheme.tex version 0.22
Free Macintosh Scheme
----------------------------------------------------------------------
Message-ID: <1990Jun30.113103.5377@idt.unit.no>
Date: 30 Jun 90 11:31:03 GMT
From: "Even A. Karlsson" <eru!luth!sunic!nuug!sigyn.idt.unit.no!even@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: call/cc
I have problem concerning call/cc. I want to pass some extra parameter
along with the current continuation to a continuation, and I don't see
how that is possible with call/cc. This is useful when modelling
the coroutine aspect of classes in Simula where detach implicitly
returns an environment (the class object) and a continuation (the rest
of the body).
Even-Andre Karlsson, IDT, NTH, NORWAY, even@idt.unit.no
------------------------------
Message-ID: <22967@boulder.Colorado.EDU>
Date: 30 Jun 90 15:53:22 GMT
From: Dirk Grunwald <grunwald@boulder.colorado.edu>
To: scheme@mc.lcs.mit.edu
Subject: xscheme.tex version 0.22
I've updated my 'tex' version of xscheme.doc to version 0.22 - it's
available in .dvi & .tex format via anonymous FTP from
foobar.colorado.edu.
------------------------------
Message-ID: <49352@iuvax.cs.indiana.edu>
Date: 30 Jun 90 15:53:45 GMT
From: Raja Sooriamurthi <daemon@iuvax.cs.indiana.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: call/cc
In comp.lang.scheme you write:
>I have problem concerning call/cc. I want to pass some extra parameter
>along with the current continuation to a continuation, and I don't see
>how that is possible with call/cc. This is useful when modelling
>the coroutine aspect of classes in Simula where detach implicitly
>returns an environment (the class object) and a continuation (the rest
>of the body).
I don't know if I understand your question clearly, but will the below
outline solve your problem?
(define receiver
(lambda (x)
(lambda (current-cont)
.
body
.)))
(call/cc (receiver extra-param))
- Raja
raja@silver.ucs.indiana.edu
------------------------------
Message-ID: <601@argosy.UUCP>
Date: 30 Jun 90 22:54:44 GMT
From: "Jay R. Freeman" <argosy!freeman@decwrl.dec.com>
To: scheme@MC.lcs.mit.edu
Subject: Free Macintosh Scheme
I have written a shareware Scheme implementation for the Apple
Macintosh. Until 1 August 1990, I will be happy to (US) mail a free
copy to anyone who sends me a 3.5-inch 800K disk and a self-addressed
return mailer WITH ENOUGH POSTAGE to get it back to you.
"Free" means that I encourage recipients of disks thus obtained to
ignore the program's built-in appeal for a shareware donation.
Mail to:
Jay Reynolds Freeman
P. O. Box 60628
Palo Alto, CA, 94306-0628
If I should get more requests than I can handle, I will have to
return empty disks. I think that's very unlikely.
For those who don't know, Scheme is a dialect of Lisp. For those
who do know, my implementation is a nearly-complete "R3" Scheme
interpreter, with a few extra features. It should run on a Mac Plus
or on any later Macintosh.
I have no FTP access and subscribe to no commercial on-line
services, so I cannot get my project to the various usual places, and
the distribution seems too large for comp.binaries.mac.
I hope it does not breach netiquette to post this item: Shareware
appears regularly on comp.binaries.<etc>, so I concluded it was OK.
-- Jay Reynolds Freeman
<canonical disclaimer -- all opinions herein are my own>
------------------------------
End of Scheme Digest
********************
∂03-Jul-90 0023 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #410
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 3 Jul 90 00:23:21 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA13812; Tue, 3 Jul 90 03:17:36 EDT
Received: from lcs.mit.edu (mintaka.lcs.mit.edu) by zurich.ai.mit.edu; Tue, 3 Jul 90 03:14:55 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa12078;
3 Jul 90 2:46 EDT
Message-Id: <DIGEST.184.900703.023045.30@MC.LCS.MIT.EDU>
Date: 3 Jul 90 02:30:45 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #410
Scheme Digest #410 3 Jul 90 02:30:45 EDT
Today's Topics:
Address Change
Common-lisp to Scheme translation (2 messages)
DEC Scheme->C under SCO Unix 386 works!
----------------------------------------------------------------------
Message-ID: <9007021419.AA25242@csserver.cs.mtu.edu>
Date: Mon, 2 Jul 90 10:19:04 EDT
From: John Lowther <john@cs.mtu.edu>
To: Scheme@MINTAKA.lcs.mit.edu
CC: john@cs.mtu.edu
Subject: Address Change
Please change my email address to
john@cs.mtu.edu
Thanks,
John Lowther
Michigan Technological University
------------------------------
Message-ID: <WA.90Jul2124002@raven.cad.mcc.com>
Date: 2 Jul 90 17:40:02 GMT
From: Wayne Allen <cs.utexas.edu!milano!cadillac!wa@yale-zoo.arpa>
To: scheme@MC.lcs.mit.edu
Subject: Common-lisp to Scheme translation
I am interested in any work concerning the translation of Common Lisp
to Scheme. I am particularly concerned with actual text translation,
although I realize that practical translation also requires the use of
"compatability" packages.
Any references to papers or working systems would be greatly appreciated.
I will post a summary of direct email replies.
Thanks
_
W | Wayne Allen, wa@mcc.com uunet!cs.utexas.edu!milano!cadillac!wa
| MCC/CAD, 3500 West Balcones Center Dr, Austin, Tx 78759 (512)338-3754
------------------------------
Message-ID: <5987@bgsuvax.UUCP>
Date: 2 Jul 90 21:29:23 GMT
From: Walter Maner <cs.utexas.edu!tut.cis.ohio-state.edu!bgsuvax!maner@yale-zoo.arpa>
To: scheme@mc.lcs.mit.edu
Subject: Re: Common-lisp to Scheme translation
From article <WA.90Jul2124002@raven.cad.mcc.com>, by wa@raven.cad.mcc.com (Wayne Allen):
>
> I am interested in any work concerning the translation of Common Lisp
> to Scheme. I am particularly concerned with actual text translation,
> although I realize that practical translation also requires the use of
> "compatability" packages.
>
> Any references to papers or working systems would be greatly appreciated.
> I will post a summary of direct email replies.
>
Perhaps these prior postings will help.
WALT
InterNet maner@andy.bgsu.edu (129.1.1.2) | BGSU, Comp Science Dept
UUCP ... ! osu-cis ! bgsuvax ! maner | Bowling Green, OH 43403
BITNet MANER@BGSUOPIE | 419/372-2337 Secretary
Relays @relay.cs.net, @nsfnet-relay.ac.uk | FAX is available - call
-----
Path: bgsuvax!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!apple!cambridge.apple.com!alms
From: alms@cambridge.apple.com (Andrew L. M. Shalit)
Newsgroups: comp.lang.scheme
Subject: Re: Scheme to Commonlisp
Message-ID: <ALMS.89Nov10125832@brazil.cambridge.apple.com>
Date: 10 Nov 89 17:58:32 GMT
References: <8911080749.aa12548@mintaka.lcs.mit.edu> <1563@accuvax.nwu.edu>
Sender: news@cambridge.apple.com
Organization: Apple Computer Inc, Cambridge, MA
Lines: 13
In-reply-to: krulwich@ils.nwu.edu's message of 10 Nov 89 16:13:18 GMT
In article <8911080749.aa12548@mintaka.lcs.mit.edu>, S.Ross@CS (Simon Ross)
writes:
>Does anyone have any advice or experience with converting a
>program in Scheme to CommonLisp (in this case Texas Instruments
>Scheme and Vax Commonlisp)? If there is some nifty program out
>there that could do the job?
You may want to look at Pseudoscheme by Jonathon Reese. It compiles
Scheme to Common Lisp, with the exception of upward continuations.
Unfortunately, I don't have an FTP address.
-andrew
-----
Path: bgsuvax!tut.cis.ohio-state.edu!bloom-beacon!ZURICH.AI.MIT.EDU!jar
From: jar@ZURICH.AI.MIT.EDU (Jonathan Rees)
Newsgroups: comp.lang.scheme
Subject: Scheme to Commonlisp
Message-ID: <8911131932.AA26435@zurich.ai.mit.edu>
Date: 13 Nov 89 19:32:23 GMT
References: <8911080749.aa12548@mintaka.lcs.mit.edu>
Sender: daemon@bloom-beacon.MIT.EDU
Organization: The Internet
Lines: 21
Date: Wed, 08 Nov 89 12:38:51 +0000
From: Simon Ross <S.Ross@cs.ucl.ac.uk>
Does anyone have any advice or experience with converting a
program in Scheme to CommonLisp (in this case Texas Instruments
Scheme and Vax Commonlisp)? If there is some nifty program out
there that could do the job?
An old version of Pseudoscheme comes with the official VAX LISP
distribution from DEC; see the LISP$EXAMPLES directory. It lets you
run Scheme code in Common Lisp, but doesn't include a file translator.
You can get a newer version of Pseudoscheme that does include a file
translator by anonymous ftp from
zurich.ai.mit.edu:/pub/pseudo/pseudo-2-7.tar. Documentation is in
file README. Upward continuations and true tail recursion aren't
supported, but it does turn appropriately written Scheme loops into
Common Lisp PROG forms.
If you want true tail recursion or upward continuations, your task is
much more difficult.
-----
Path: bgsuvax!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!math.lsa.umich.edu!emv
From: jar@ZURICH.AI.MIT.EDU (Jonathan Rees)
Newsgroups: comp.archives
Subject: [scheme] Scheme in Common Lisp
Message-ID: <11952@stag.math.lsa.umich.edu>
Date: 8 May 90 15:57:07 GMT
Sender: news@math.lsa.umich.edu
Reply-To: jar@ZURICH.AI.MIT.EDU (Jonathan Rees)
Followup-To: comp.lang.scheme
Lines: 19
Approved: emv@math.lsa.umich.edu (Edward Vielmetti)
X-Original-Newsgroups: comp.lang.scheme
Archive-name: pseudoscheme/03-May-90
Original-posting-by: jar@ZURICH.AI.MIT.EDU (Jonathan Rees)
Original-subject: Scheme in Common Lisp
Archive-site: zurich.ai.mit.edu [18.26.0.176]
Archive-directory: pub/pseudo
Archive-files: pseudo-2-7.tar.Z
Reposted-by: emv@math.lsa.umich.edu (Edward Vielmetti)
There's something called "Pseudoscheme" available by anonymous ftp
from zurich.ai.mit.edu, file pub/pseudo/pseudo-2-7.tar (compressed:
pseudo-2-7.tar.Z). It's not really Scheme because it doesn't handle
tail recursion except where lexically obvious (i.e. loops written
using LETREC, named LET, or internal DEFINE), and it doesn't handle
continuations in general because CALL-WITH-CURRENT-CONTINUATION is
defined in the obvious way in terms of Common Lisp's BLOCK and
RETURN-FROM. Its advantage relative to something more faithful is
that it compiles Scheme to idiomatic Common Lisp, which means that
there is no performance hit relative to CL, and you get to use
whatever debugging support the underlying CL gives you.
-----
--
InterNet maner@andy.bgsu.edu (129.1.1.2) | BGSU, Comp Science Dept
UUCP ... ! osu-cis ! bgsuvax ! maner | Bowling Green, OH 43403
BITNet MANER@BGSUOPIE | 419/372-2337 Secretary
Relays @relay.cs.net, @nsfnet-relay.ac.uk | FAX is available - call
------------------------------
Message-ID: <953@barsoom.nhh.no>
Date: 2 Jul 90 22:06:24 GMT
From: Tom Ivar Helbekkmo <eru!luth!sunic!nuug!barsoom!tih@bloom-beacon.mit.edu>
To: scheme@mc.lcs.mit.edu
Subject: DEC Scheme->C under SCO Unix 386 works!
Well, guess who's happy now! :-) I've just finished installing DEC
Scheme->C (from gatekeeper.dec.com) on my SCO Unix 386 system. At
gatekeeper, I found the distribution .tar.Z, and a toolkit (newish)
for installing Scheme on 386 systems. I'm sorry I can't remember the
name of the person responsible for this great piece of work, (s)he
really deserves credit for that one! (I've removed all headers from
the shar files, and can't get out of the country with FTP right now.)
Anyway, with that toolkit to fix long filenames and things for me,
setting up the directory structure and so on was a cinch.
Still, a couple of comments. The patch kit says that exception
handling is unfinished and might not even work right on 386 systems,
and that's right. Anyway, I thought I'd share with you all what was
needed in addition. I'm using GCC 1.37.1 as my C compiler, and as
usual, I guess the job would have been harder with the Microsoft cc
that comes with this system...
I'd really like some feedback on this stuff, if you can see anything I
should have done different... First, some trifling details: In
scinit.c, I had to change <strings.h> into <string.h>. I also added
an ETEXT/STACKBASE defining section for SCO, equal to the 386ix one.
Next, signal handling. It really didn't take much to get it working,
but some changes were needed. The way it first came up, my whole
system would hang the *second* time an interrupt happened -- not
unusual when porting BSD style applications to System V... :-)
Signals have to be reinitialized whenever they're caught.
In signal.c, I added a line "signal(sig, sc_trap_handler);" to the
very start of sc_trap_handler(), so that it would always set itself up
for the next catch. I didn't bother to differentiate between
various floating point errors, I just trigger the traceback and let
it go at that. That takes care of the SIGFPE -- but there's more out
there... In scrt4.sc, there's a signal catcher in scheme. Now, I got
hold of this package to *learn* scheme, so I hope what I've done is
reasonable... I changed the line:
(define (ONSIGNAL2 sig) ((vector-ref signals sig) sig))
.. into ...
(define (ONSIGNAL2 sig)
(SIGNAL sig (vector-ref signals sig)) ; Set the signal again
((vector-ref signals sig) sig)) ; Now execute the handler
Looks to me like this should handle it, and anyway, I can now hit DEL
several times during the same 'sci' run without having my system hang
for 5 minutes followed by a core dump. :-) Problem is, I've now done
this in the scheme part of the code, while I'd really like to have
it be conditional, executed this way only for System V boxes. How
would I go about that?
Finally, here's a little bug I found in the scheme code: If I start
sci, and type a floating point number that needs scientific notation,
but has an integral mantissa, it gets printed wrong:
> 1.1e-7
1.1e-7
> 1.0e-7
1e-07.
Note the trailing '.' there, that thing will screw up GCC when it
tries to compile C source written by sccomp! For instance, I couldn't
compile testchk.sc in the test directory without hand fixing the C
source. I found the problem in scrt7.sc, in the definition of
FLOAT->CLIST, at the end of which we see
(reverse (if (memq #\. clo) clo (cons #\. clo))))
.. which I changed into ...
(reverse (if (memq #\. clo)
clo
(if (memq #\e clo)
clo
(cons #\. clo))))
The trouble was, that while the code checked for existence of a '.' in
what should be a floating point number, it forgot to look for the 'e'
used in scientific notation. With that notation, you can't just add a
trailing '.' -- in fact, you emphatically shouldn't. Could I have
chosen a more efficient way of doing it, though?
Whatever else may be or not be, DEC Scheme->C looks great: I've run a
couple of benchmarks through it, and as far as I can tell, the
compiler is pretty good at what it does. With this thing running
behind EMACS, I'd say that developing in an interpreted environment,
and then compiling when the code works and you want SPEED is very
feasible indeed.
Looking forward to lots of fun with scheme!
-tih
--
Tom Ivar Helbekkmo, NHH, Bergen, Norway. Telephone: +47-5-959205
tih@barsoom.nhh.no, thelbekk@norunit.bitnet, edb_tom@debet.nhh.no
------------------------------
End of Scheme Digest
********************
∂03-Jul-90 2356 SCHEME-REQUEST@mc.lcs.mit.edu Scheme Digest #411
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 3 Jul 90 23:56:51 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02208; Wed, 4 Jul 90 02:55:54 EDT
Received: from lcs.mit.edu (mintaka.lcs.mit.edu) by zurich.ai.mit.edu; Wed, 4 Jul 90 02:52:52 edt
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa01165;
4 Jul 90 2:51 EDT
Message-Id: <DIGEST.184.900704.021545.38@MC.LCS.MIT.EDU>
Date: 4 Jul 90 02:15:45 EDT
From: Automatic Scheme Digestifier <Scheme-Request@lcs.mit.edu>
Reply-To: Scheme@lcs.mit.edu
To: Scheme@lcs.mit.edu
Subject: Scheme Digest #411
Scheme Digest #411 4 Jul 90 02:15:45 EDT
Today's Topics:
Is the R4 report out yet?
Common-Lisp -> Scheme (NOT THE OTHER WAY AROUND!)
----------------------------------------------------------------------
Message-ID: <1990Jul3.183348.18124@eplrx7.uucp>
Date: 3 Jul 90 18:33:48 GMT
From: Walt Leipold <eplrx7!leipold@louie.udel.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: Is the R4 report out yet?
In article <577@argosy.UUCP> freeman@maspar.COM (Jay R. Freeman) writes:
>A bibilography in a recent SigPLAN notices suggests that the R4 report
>has been published. Is that so? Can someone tell me how to obtain a
>copy (where to write and how much it costs)?
Even better, is the R4 report going to be *published* in SigPLAN notices?
The R3 report was, as I recall.
--
"As long as you've lit one candle, Walt Leipold
you're allowed to curse the darkness." (leipolw%esvax@dupont.com)
--
--
The UUCP Mailer
------------------------------
Message-ID: <9007032108.AA19805@mailhost.samsung.com>
Date: Tue, 3 Jul 90 09:12:41 EDT
From: gjc@mitech.com
Reply-To: gjc@mitech.com
To: scheme@lcs.mit.edu
Subject: Common-Lisp -> Scheme (NOT THE OTHER WAY AROUND!)
The fellow was asking about Common-Lisp -> Scheme, not Scheme to commonlisp.
I've had to think about this a lot, primarily because we have a large
code, Macsyma, which is written in Maclisp, and which we want to
extend and develop into the future along side newer code.
(Ref: Paradigm Associates Inc, and Lawrence Livermore Labs)
All things considered it appears that good quality Scheme implementations
are available for more machines than any common lisp.
This fact is supported by the obvious engineering implications of
the languages: That a good Scheme is easier to implement than a
good common lisp. (A good common lisp has to be bad, by it vary nature,
in some ways, when size and power/complexity are considered).
Be that as it may, the major problem with Common-Lisp -> Scheme
translation has been the need to preserve order-of-evaluation of
arguments to procedures, and in LET statements.
The straightforward translation of (foo (a) (b) (c)) turns into:
(let ((temp1 nil)(temp2 nil)(temp3 nil))
(setq temp1 (a))
(setq temp2 (b))
(setq temp3 (c))
(foo temp1 temp2 temp3))
If you have many nested procedure calls you can imagine the mess
that generates. It best it ends up making the scheme compiler
do tons of extra work in optimizing away those cases that it can,
and at worse it results in some very poor code.
The maclisp AND/OR construct, which is quite elegantly used in many
places in macsyma, e.g.
Things along these lines:
(defun get-item (a kind)
(or (get a 'kind) (get kind 'default)))
Where the OR needs to be translated into:
(let ((temp1 (get a 'kind)))
(if (NOT (NULLP temp1)) temp1 (get kind 'default)))
If you decide to do some of your own code-analysis optimization
before generating a lot of extra temporaries then you are duplicating
functionality that may be in the best scheme compilers.
However, none of those compiler will be able to utilize the kind
of globally known information about a program like Macsyma
which could be handled within the scope of an all-purpose front-end
that included a database that was carefully updated as the program
was processed.
-gjc
------------------------------
End of Scheme Digest
********************